Technique appropriée pour stocker les données d'événement des utilisateurs

12

Je suis surtout un autodidacte en matière de conception de bases de données. Je pose cette question parce que je me suis fixé sur cette structure commune, mais je me demande si c'est la méthode la plus efficace ou «standard de l'industrie».

La plupart des bases de données que je conçois ont une table utilisateur, puis une activité de personne est suivie dans une autre table. Je comprends que la beauté de la base de données est d'avoir ce genre d'efficacité, mais la table d'activités rassemblera de nombreux événements assez rapidement, juste de chaque utilisateur l'utilisant régulièrement, devenant ainsi une énorme table assez rapidement avec une utilisation modérée de l'utilisateur. Est-ce la meilleure pratique de simplement la laisser grandir de cette façon? Ou est-ce un niveau de tables, ou une répartition en différentes tables en fonction des dates, ou par nombre d'utilisateurs, ou autre chose?

+--------------------+                   +------------------------+
|   UserData         |                   |   Activity             |
+-=------------------+                   +------------------------+
| ID     (auto uint) | <--1-to-many-+    | ID  (auto uint)        |
| UserName (text)    |              +--> | UserID (uint)          |
| Email    (text)    |                   | Timestamp (time)       |
| additional info... |                   | Type (ID to elsewhere) |
+--------------------+                   | additional info...     | 
                                         +------------------------+

Je voudrais juste savoir où je peux améliorer quoi que ce soit, pour m'aider à apprendre.

database-design database-recommendation CenterOrbit
la source

Réponses:

5

Ou est-ce un niveau de tables, ou une répartition en différentes tables en fonction des dates, ou par nombre d'utilisateurs, ou autre chose?

Vous voudrez peut-être examiner le concept de «partitionnement» dans votre base de données. La plupart des SGBDR ont un support pour eux (par exemple, mysql , oracle , sql server , postgresql ). Fondamentalement, vous laissez le SGBDR gérer le processus de création / gestion du fait que chaque mois / année / tout ce qui est stocké dans une table distincte, tandis que le code qui y accède la traite comme une grande table.

Vous pouvez le partitionner par nom d'utilisateur, date ou tout ce qui sera utilisé le plus fréquemment pour accéder aux données. (il y a des avantages / inconvénients à le faire centré sur l'utilisateur vs centré sur la date ... mais je ne sais pas si vous voulez que j'entre dans tout cela)

Joe
la source
Merci @Joe, je l'ai lu sur Wikipedia ( en.wikipedia.org/wiki/Partition_%28database%29 ) et certains des liens que vous avez publiés. Le type de partitionnement auquel vous vous référez serait le partitionnement horizontal. C'est une fonctionnalité que je ne connaissais pas jusqu'à présent. Je vais maintenant poser une nouvelle question: dba.stackexchange.com/questions/4134/… qui demande de bonnes pratiques de partitionnement.
CenterOrbit
6

Vous avez fait une très bonne observation. La table d' activité va grandir rapidement et grand. Ce que j'ai fait dans le passé, c'est archiver les données plus anciennes (disons plus de 14 jours) dans une table ActivityHistory . Cela permet de conserver la table Activity à une taille gérable et si vous avez besoin de faire des recherches, vous pouvez toujours consulter la table ActivityHistory .

Michael Riley - AKA Gunny
la source
1
J'aime votre idée, et c'est une solution qui s'adaptera à presque toutes les configurations de base de données, même celles qui ne prennent pas en charge la solution @Joe. Pourtant, cela compliquerait également certaines des requêtes impliquées si vous deviez accéder aux anciennes données archivées et créer la nécessité d'ajouter une jointure d'union. Très bien cependant, je n'ai pas pensé à cette approche. Je vous remercie.
CenterOrbit
Ce n'est pas nécessairement compliqué, vous pouvez jouer avec les chaînes de connexion de l'application pour choisir l'historique db dans le cas où les données sont plus anciennes. Ou vous pouvez utiliser des serveurs liés dans les procédures, et dans le cas où certains datetime sont plus anciens que x jours, accédez au serveur lié aux archives au lieu du serveur principal.
Marian
C'est encore moins compliqué si la table ArchiveHistory se trouve dans la même base de données.
Michael Riley - AKA Gunny