MySQL : plusieurs tables ou une seule table avec plusieurs colonnes ?

Question

Il s'agit donc plutôt d'une question de conception.

J'ai une clé primaire (disons l'ID de l'utilisateur), et j'ai des tonnes d'informations associées à cet utilisateur.

Devrais-je avoir plusieurs tableaux répartis en catégories selon les informations, ou un seul tableau avec de nombreuses colonnes ?

La façon dont j'avais l'habitude de procéder était d'avoir plusieurs tables, par exemple une table pour les données d'utilisation de l'application, une table pour les informations sur le profil, une table pour les jetons du back-end, etc. pour que les choses restent organisées.

Récemment, quelqu'un m'a dit qu'il valait mieux ne pas procéder de cette façon et qu'il n'y avait pas de problème à avoir un tableau avec beaucoup de colonnes. Le problème est que toutes ces colonnes ont la même clé primaire.

Je suis assez novice en matière de conception de bases de données. Quelle est la meilleure approche et quels sont les avantages et les inconvénients ?

Quelle est la manière conventionnelle de procéder ?

Answer 1

Chaque fois qu'une information est unique (chaque utilisateur a un nom et un mot de passe), il est probablement préférable d'avoir une seule table, car cela réduit le nombre de jointures que la base de données devra effectuer pour récupérer les résultats. Je pense que certaines bases de données ont une limite sur le nombre de colonnes par table, mais je ne m'en préoccuperais pas dans les cas normaux, et vous pouvez toujours les diviser plus tard si vous en avez besoin.

Si les données sont de type "one-to-many" (chaque utilisateur possède des milliers de lignes d'informations sur son utilisation), elles doivent être réparties dans des tables distinctes afin de réduire les données en double (les données en double gaspillent de l'espace de stockage, de l'espace de cache et rendent la base de données plus difficile à maintenir).

Vous pouvez trouver l'article de Wikipedia sur normalisation de la base de données intéressant, puisqu'il examine en profondeur les raisons de cette situation :

La normalisation des bases de données est le processus d'organisation des champs et des tables d'une base de données relationnelle afin de minimiser les redondances et les dépendances. La normalisation implique généralement la division de grandes tables en tables plus petites (et moins redondantes) et la définition de relations entre elles. L'objectif est d'isoler les données de sorte que les ajouts, les suppressions et les modifications d'un champ puissent être effectués dans une seule table et se propager ensuite dans le reste de la base de données via les relations définies.

Dénormalisation est également une chose dont il faut tenir compte, car il existe des cas où la répétition des données est préférable (car elle réduit la quantité de travail que la base de données doit effectuer lors de la lecture des données). Je vous recommande vivement de normaliser vos données autant que possible pour commencer, et de ne les dénormaliser que si vous avez conscience de problèmes de performances dans des requêtes spécifiques.

Answer 2

Une seule grande table est souvent un mauvais choix. Les tables connexes sont ce pour quoi les bases de données relationnelles ont été conçues. Si vous indexez correctement et que vous savez comment écrire des requêtes performantes, elles fonctionneront parfaitement.

Lorsque les tables comportent trop de colonnes, la taille réelle de la page sur laquelle la base de données stocke les informations peut poser problème. Soit l'enregistrement peut finir par être trop grand pour la page, auquel cas vous pouvez finir par ne pas être en mesure de créer ou de mettre à jour un enregistrement spécifique, ce qui rend les utilisateurs mécontents, soit vous pouvez (dans SQL Server au moins) être autorisé à un certain dépassement pour des types de données particuliers (avec un ensemble de règles que vous devez rechercher si vous faites cela), mais si beaucoup d'enregistrements dépassent la taille de la page, vous pouvez créer des problèmes de performance énormes. Maintenant, comment MYSQL gère les pages et si vous avez un problème lorsque la taille potentielle de la page devient trop grande, c'est quelque chose que vous devriez regarder dans la documentation de cette base de données.

Answer 3

J'ai un bon exemple. Une base de données excessivement normalisée avec l'ensemble de relations suivant :

people -> rel_p2staff -> staff

et

people -> rel_p2prosp -> prospects

Où people a les noms et les détails des personnes, staff a juste les détails de l'enregistrement du staff, prospects a juste les détails des prospects, et les tables rel sont des tables de relation avec des clés étrangères de people liant au staff et aux prospects.

Ce type de conception s'applique à l'ensemble de la base de données.

Maintenant, pour interroger cet ensemble de relations, il faut à chaque fois faire une jointure multi-table, parfois 8 et plus. Cela a bien fonctionné jusqu'au milieu de cette année, quand cela a commencé à devenir très lent maintenant que nous avons dépassé 40000 enregistrements de personnes.

L'indexation et tous les fruits mûrs ont été épuisés l'année dernière, toutes les requêtes sont optimisées à la perfection. C'est la fin de la route pour la conception normalisée particulière et la direction a maintenant approuvé une reconstruction de toute l'application qui en dépend ainsi qu'une restructuration de la base de données, sur une période de 6 mois. $$$$ Ouch.

La solution sera d'avoir une relation directe pour people -> staff y people -> prospect

Answer 4

posez-vous ces questions si vous mettez tout dans un tableau, vous disposez de plusieurs lignes pour que l'utilisateur? Si vous devez mettre à jour un utilisateur voulez-vous conserver une piste de vérification? L'utilisateur peut-il avoir plus d'une instance d'un élément de données? (comme le numéro de téléphone par exemple) vous avez un cas où vous voudrez peut-être ajouter un élément ou ensemble d'éléments plus tard? si vous répondez oui, alors très probablement, vous voulez demander à l'enfant de tables avec des relations de clé étrangère.

Les Pros du parent/enfant tables est de l'intégrité des données, la performance via des index (oui, vous pouvez le faire sur une table à plat aussi) et de l'OMI plus facile à maintenir si vous avez besoin d'ajouter un champ plus tard, surtout si elle est un champ obligatoire.

Les inconvénients de la conception est plus difficile, les requêtes deviennent un peu plus complexes

Mais, il existe de nombreux cas où une grande table à plat seront appropriés, de sorte que vous avez à regarder votre situation de décider.

Answer 5

J'ai déjà fini de faire une sorte de conception de base de données. Pour moi, cela dépend de la difficulté du système avec la gestion de base de données ; oui, c'est vrai d'avoir des données uniques à un seul endroit, mais il est vraiment difficile de faire des requêtes avec une base de données trop normalisée avec beaucoup d'enregistrements. Combinez simplement les deux schémas ; utilisez une table énorme si vous pensez que vous aurez des enregistrements massifs qui sont difficiles à maintenir comme facebook, gmail, etc. et utilisez une table différente pour un ensemble d'enregistrements pour un système simple... c'est juste mon opinion... j'espère que cela peut aider... faites-le... vous pouvez le faire... :)