Modèle de base de données pour garder une trace de goûts / actions / commentaires sur des poteaux de blog au fil du temps
Mon objectif est de garder une trace des postes populaires sur différents sites de blog basés sur une activité de réseau social à tout moment. L'objectif n'est pas de simplement obtenir le plus populaire maintenant, mais de trouver des messages populaires que ceux des autres postes sur le même blog. Par exemple, je suis un blog technique, un blog sportif et un blog de potins. Le blog technologique obtient plus de lectorat que les deux autres blogs, donc dans les numéros bruts, chaque message sur le blog technique voit toujours des vues sur les deux autres. Donc, disons que la pochette de blog de technologie moyenne obtient 500 goûts Facebook et les deux autres obtiennent une moyenne de 50 goûts par courrier. Ensuite, lorsqu'il y a un article de blog sportif qui a 200 mme de fb et un poteau de blog de potins avec 300 tandis que les poteaux de blog technologiques ont aujourd'hui 500 goûts, je veux mettre en évidence les articles de blog sportifs et des commérages (plus de goûts que la moyenne du blog de Tech avec plus de # de goûts mais juste moyenne pour le blog)
L'approche que je pense à prendre consiste à effectuer une entrée dans une base de données pour chaque publication de blog. Chaque X minutes (disons toutes les 15 minutes), je vérifierai le nombre de goûts/actions/commentaires Une entrée a reçu sur tous les réseaux sociaux (Facebook, Twitter, Google +, Linkein). Donc, au fil du temps, il y aura une histoire de goûts pour chaque poteau de blog, c'est-à-dire
post 1234
after 15 min: 10 fb likes, 4 tweets, 6 g+
after 30 min: 15 fb likes, 15 tweets, 10 g+
...
...
after 48 hours: 200 fb likes, 25 tweets, 15 g+
En gardant une histoire comme celle-ci pour chaque article de blog, je peux connaître le nombre moyen de goûts/actions/tweets à tout intervalle de délai. Donc, par exemple, le nombre moyen de fb aime pour tous les poteaux de blogs 48 heures après l'affichage d'une cinquantaine d'affichage est de 50 ans et qu'un poste particulier a 200, je peux marquer cela comme un post et une fonctionnalité populaires/en surbrillance. Une contrepartie de la conception consiste à être capable de interroger facilement les valeurs (goûts/actions) pour un châssis temporel spécifique, c'est-à-dire FB Likes après 30 minutes ou des tweets après 24 heures pour calculer des moyennes avec lesquelles comparer (ou devraient Les moyennes soient stockées dans sa propre table?)
Si cette approche est défectueuse ou pourrait utiliser une amélioration s'il vous plaît faites le moi savoir, mais ce n'est pas ma principale question. Ma question principale est ce que devrait-il ressembler un système de base de données pour stocker cette information?
En supposant que l'approche ci-dessus soit prise, j'essaie de comprendre ce qu'un schéma de base de données pour stocker les goûts au fil du temps ressemblerait. Je suis tout neuf pour les bases de données, en faisant une lecture de base, je vois qu'il est conseillé de créer une base de données 3NF. J'ai monté le schéma possible suivant.
Schema 1
DB Popular Posts
Table: Post
post_id ( primary key(pk) )
url
title
Table: Social Activity
activity_id (pk)
url (fk)
type (i.e. facebook,Twitter,g+)
value
timestamp
C'était mon instinct initial (base sur mes connaissances en DB très limitées). Autant que je stipiste, ce schéma serait 3nf? J'ai cherché des conceptions de modèle de base de données similaire, et j'ai trouvé cette question sur Stackoverflow, https://stackoverflow.com/questions/11216080/Data-Structure-for-Storing-Height-and-PhereCover- Time-for-Users-Users . Le scénario de cette question est similaire (enregistrement du poids/hauteur des utilisateurs des heures supplémentaires). Prendre la réponse acceptée pour cette question et l'appliquer à mon modèle entraîne quelque chose comme:
Schema 2 (comme ci-dessus, mais décompose l'activité sociale en 2 tables)
DB Popular Posts
Table: Post
post_id (pk)
url
title
Table: Social Measurement
measurement_id (pk)
post_id (fk)
timestamp
Table: Social stat
stat_id (pk)
measurement_id (fk)
type (i.e. facebook,Twitter,g+)
value
L'avantage que je vois dans le schéma 2 est que je voudrais probablement accéder à toutes les valeurs pendant une période donnée, c'est-à-dire lorsque vous effectuez une mesure à 30min après une publication après un poste, je choisirai simultané le numéro de contrôle de FB Likes, des actions FB, des commentaires FB, Tweets, G +, LinkedIn. Donc, avec ce schéma, il peut être plus facile d'obtenir toutes les statistiques d'une mesure_id correspondant à un certain temps, c'est-à-dire toutes les statistiques sociales pour la poste 1234 au moment de la X.
Une autre pensée que j'avais, c'est que cela n'a pas de sens de comparer le nombre de personnes de FB avec le nombre de tweets ou des actions G +, il est peut-être logique de séparer chaque mesure sociale à sa propre table?
SCHEMA 3
DB Popular Posts
Table: Post
post_id (pk)
url
title
Table: fb_likes
fb_like_id (pk)
post_id (fk)
timestamp
value
Table: fb_shares
fb_shares_id (pk)
post_id (fk)
timestamp
value
Table: tweets
tweets__id (pk)
post_id (fk)
timestamp
value
Table: google_plus
google_plus_id (pk)
post_id (fk)
timestamp
value
Comme vous pouvez le constater, je suis généralement perdu/incertain de quelle approche à prendre.
Je suis sûr que ce type typique de problème de base de données (stockage des heures supplémentaires, c'est-à-dire une statistique de température) qui doit avoir une solution commune. Existe-t-il un modèle/modèle de conception pour cela, a-t-il un nom? J'ai essayé de chercher "la collecte de données périodique de la base de données" ou "mesures de base de données au fil du temps" mais n'a rien trouvé de spécificité.
Quel serait un modèle approprié pour résoudre les besoins de ce problème?
Alors, lisez ceci, je vois les spécifications suivantes:
Je veux suivre la popularité des blogs. Ceci est accompli en comparant leurs "goûts" agrégés ou autre (retweets, etc.) sur une période de 48 heures à leur niveau "normal".
Je veux mettre à jour mon nombre actuel de goûts, Retweets, sur un intervalle périodique configurable.
Je dois être capable de calculer l'effet des goûts, des retweets, etc. indépendants les uns des autres.
Semble le moyen le plus simple serait d'utiliser votre troisième schéma. Il vous permet toujours de collecter toutes les statistiques simultanément ou indépendamment. Le seul effet serait si indépendant, il y aura toujours une partie de la fenêtre du temps où votre classement actuel ne reflète pas le classement vrai, s'il est simultané, votre classement vient de retarder la "vérité" par le taux de mise à jour.
Quoi qu'il en soit, vous pouvez ensuite exécuter périodiquement une requête pour chaque Post_ID, calculez la métrique FB aime la métrique sur les 48 heures précédentes + Tweets Metric sur les 48 heures précédentes, etc., et utilisez-la pour mettre à jour votre classement.
Pour répondre aux questions que vous souhaitez poser à votre candidature, vous devez stocker des informations sur trois choses: blogs, postes et activités.
Les blogs sont simplement des conteneurs pour les poteaux, car vous avez dit que vous souhaitez classer/mettre en évidence des postes dans chacun des blogs, et non sur les blogs, vous devez donc savoir quels postes appartiennent à quels blogs. Les postes sont assez statiques, mais sont indépendants de leurs blogs respectifs et de leur activité sociale. L'activité sociale est très dynamique (on dirait probablement une courbe de cloche au fil du temps) et il peut ne pas être une coupure pour la découverte de l'activité sociale au fil du temps.
Maintenant, cela vous laisse avec trois entités centrales: blog, post et activité. Le schéma pourrait ressembler à quelque chose comme ça:
blog post activity
---------- ----------- --------
blog_id (pk) post_id (pk) activity_id (pk)
url blog_id (fk) post_id (fk)
title url facebook_likes
title Twitter_tweets
google_shares
Cela suppose que vous n'êtes pas intéressé à stocker l'activité réelle des médias sociaux, c'est-à-dire de stocker l'URL du tweet, etc., et de stocker simplement les résultats de la découverte de l'activité sociale pour chaque poste. Si vous exécutez ceci pour un nouveau message aujourd'hui, vous inséreriez les résultats dans la table d'activité. Si vous exécutez à nouveau la découverte demain, une ligne de la table d'activité existerait déjà et vous l'informeriez avec les résultats à ce moment-là.
(Feature Creep Alert: Si vous stockez de nouvelles lignes pour chaque découverte, vous pouvez obtenir des informations précieuses sur la manière dont l'activité des médias sociaux se développe au fil du temps. Par exemple, vous pouvez voir quel support est rapide à ramasser le poste et à la décolleté. Et Vous pouvez créer des graphiques utiles qui pimenteraient la présentation. Afin de faire cela, vous auriez besoin de stocker exactement les mêmes choses, mais ajoutez également une date/un horodatage pour la découverte.)
Une clé étrangère relie la rangée à une rangée d'une autre table. Donc, par exemple, un blog a plusieurs poteaux et un message appartient à un seul blog. Ceci est une relation à une autre - un blog comporte de nombreux postes, un message appartient à un seul seul blog. Un blog pourrait avoir le blog_id 1. Tous les messages qui appartiennent à ce blog auraient leur blog_id défini sur 1.
Techniquement, vous pouvez éliminer la table d'activité et déplacer les colonnes dans la table de poste si vous le souhaitez. La raison pour laquelle je vais les garder séparées, c'est qu'ils sont des entités distinctes et que cela laisse la porte ouverte pour des changements futurs. Par exemple, vous pouvez facilement ajouter un horodatage et stocker l'activité comme quelque chose qui varie au fil du temps. De plus, vous pourriez la rompre encore plus et ajouter une autre table (E.G. Action) qui stocke les actions des médias sociaux actuels (Tweets, les goûts, etc.).
En optimisation, vous pouvez calculer et stocker les métriques sur les entités respectives (c'est-à-dire la table et la poste) si nécessaire. C'est principalement une préoccupation lorsqu'il s'agit de lire les données après avoir fait la découverte. N'oubliez pas que vous allez informer et mettre à jour la base de données très peu comparée au nombre de fois que vos utilisateurs loueront les informations - en d'autres termes, la dénormalisation et l'agrégation réduiront le nombre de requêtes nécessaires pour produire les données que vous souhaitez présenter à votre utilisateurs.