En supposant que nous devons enregistrer tous les actifs des utilisateurs d'une communauté, Je suppose que dans une brève période, notre base de données deviendra très énorme ; Ma question est donc la suivante: est-ce quand même un compromis acceptable ( d'avoir une énorme table de base de données ) afin d'offrir ce type de service? Ou nous pouvons le faire de manière plus efficace? EDIT 2:
Ma table est déjà optimisée afin de stocker uniquement
3 Réponses :
Avez-vous besoin de stocker l'activité spécifique de chaque utilisateur ou souhaitez-vous simplement enregistrer le type d'activité qui se produit dans le temps. Si ce dernier, vous pourriez alors considérer quelque chose comme RRDTool (ou une approche similaire) et stocker la quantité d'activité sur différents horodataires dans un tampon circulaire, dont la taille reste constante au fil du temps. Voir http://en.wikipedia.org/wiki/rrrdtool .
cas: lorsque toutes les activités utilisateur ont des tables différentes. Par exemple. Comme, commentaire, post, devenez membre.
Alors, ces table doivent avoir une clé associant l'entrée à un utilisateur. Compte tenu d'un utilisateur, vous pouvez obtenir des activités récentes en interrogeant chaque tableau par le User_Key.
Par conséquent, si vous n'avez pas encore de schéma ou que vous êtes privilégié de le changer, allez avec différentes tables pour différentes activités et recherchez plusieurs activités.
Case: Il existe certaines activités qui disent génériques et n'ont pas de table individuelle pour elle
a ensuite une table pour des activités génériques et la recherche avec d'autres tables d'activité.
Je travaille en fait sur un système similaire, donc je suis intéressé par les réponses que vous obtenez.
Pour mon projet, une comptabilité historique complète n'était pas importante, nous avons donc choisi de garder la table assez maigre beaucoup comme ce que vous faites. Nos tables ressemblent à ceci comme suit: P>
CREATE TABLE `activity_log_entry` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`event` varchar(50) NOT NULL,
`subject` text,
`publisher_id` bigint(20) NOT NULL,
`created_at` datetime NOT NULL,
`expires_at` datetime NOT NULL,
PRIMARY KEY (`id`),
KEY `event_log_entry_action_idx` (`action`),
KEY `event_log_entry_publisher_id_idx` (`publisher_id`),
CONSTRAINT `event_log_entry_publisher_id_user_id`
FOREIGN KEY (`publisher_id`)
REFERENCES `user` (`id`) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8
oui des coutures comme si nous faisons la même chose;) mon problème est: quand, par exemple, quelqu'un est en train d'éditer votre propre profil et il déclenche plusieurs fois "Enregistrer les modifications", alors nous avons un tas d'entrées inutiles de DB, même chose sur "Log -in "et" déconnexion "donc dans ce cas, je suppose que je devrais simplement" mettre à jour "au lieu de" insertion ", sinon si on affiche un commentaire ou une nouvelle, nous" insérer "continuellement. Qu'est-ce que tu fais quoi? +1
@Julie: En fait, nous venions de discuter de ce vendredi ... nous parlions d'éventuellement déplacer le type d'entité à partir de la série d'objets valeur de valeur (ou la duplication) à sa propre colonne ainsi que d'ajouter une mise à jour à la colonne. De cette façon, nous avons pu choisir de simplement mettre à jour le sujet et mises à jour_at des colonnes d'un événement donné si elles étaient dans une certaine période (selon 12-2 24 heures) entraînant moins Entrées ... Nous n'avons pas encore décidé, mais cela est certainement sur notre radar.
Je sais que c'est une vieille réponse, mais je voulais juste noter que Bigint (20) ne limite pas vraiment la taille des données de la colonne; Il contrôle simplement l'option ZerOfill pour contrôler les zéros précédents.
Comment comptez-vous utiliser les données du journal et quelle fréquence?
@Prodigitaux: il sera utilisé dans un autre système de type social. Cela ressemblera donc à un classique, a déclaré John Doe, commenté, visité, ajouté, téléchargé, posté, etc ..., si assez souvent je suppose.
forums.mysql.com/read.php?153,268034, 268061 # MSG-268061
@CALUM: Merci pour le lien! ;)
Pas de soucis :) Celui-ci a l'air bien! DatabaseAnswers.org/data_models/social_networking/index.htm
@CALUM Le premier lien est malheureusement.