Stockage des données d'action utilisateur dans MySQL: une ou plusieurs tables?

Question

Je construis un site Web dans lequel les utilisateurs peuvent effectuer une variété d'actions et ils obtiennent un nombre variable de "points" ou "badges" pour effectuer des actions spécifiques. Certaines données doivent être stockées quel que soit le type d'action effectué par l'utilisateur, tel que l'ID utilisateur, le type d'action, un horodatage, le total de points actuel et tout badge attribué. Mais en fonction du type d'action qu'un utilisateur effectue, certaines données spécifiques au type d'action doivent être stockées, y compris les données d'image dans les objets BLOB.

Une option consiste à inclure tous les champs pour tous les types d'action dans la table d'actions. Malheureusement, chacune de ces colonnes stockerait uniquement des données pour la petite proportion d'actions correspondant au type d'action approprié. Donc, je voudrais avoir un grand nombre de champs vides (y compris les BLOB) avec cette approche.

L'autre option consiste à inclure une table pour chaque type d'action en plus de la table d'actions ci-dessus. Chaque table de type action possède une clé étrangère à l'action correspondante dans la table d'actions. Cela permettrait de mieux organiser la table des actions, mais elle introduit la possibilité que la table des actions ne soit plus synchronisée avec les tables de type action. Je m'interroge également sur les implications de performance d'avoir à faire un grand nombre de jointures sur les différentes tables de type action chaque fois que j'obtiens des données de la table des actions.

Enfin, j'optimise pour la vitesse plutôt que pour la taille. Comment dois-je aborder ce dilemme?

Answer 1

Habituellement, éviter les jointures dans les grandes tables est une bonne pratique pour la vitesse, mais cela dépend vraiment de votre utilisation.

Si vous prévoyez d'effectuer des regroupements sur la table d'actions, je recommande fortement d'utiliser l'approche de table unique. Si tout ce que vous faites est une extraction d'index à une seule ligne (l'utilisateur a fait cette action particulière), alors peut-être que l'utilisation de tables différentes sera plus efficace. Vous serez en mesure d'interroger la table spécifique, et comme il est plus petit, il peut être plus réactif. Une pratique que je vois beaucoup a des champs génériques (number1, number2, ... string1, string2 ...) et une table de mapping qui décrit chaque champ en fonction du type d'action. L'avantage de cette pratique est que la table est plus densément peuplée. L'inconvénient est que la compréhension des données dans le tableau devient difficile et que la synchronisation de la cartographie est un travail difficile. Je ne l'utiliserais que s'il y avait une bonne raison. Par exemple, vous avez plus de cinquante types d'actions différentes (dans ce cas, la gestion de cinquante tables n'est pas non plus un pique-nique).