MySQL: plusieurs tables ou une table avec plusieurs colonnes?
Donc, ceci est plus une question de conception.
J'ai une clé primaire (par exemple l'ID de l'utilisateur) et des tonnes d'informations sont associées à cet utilisateur.
Devrais-je avoir plusieurs tableaux divisés en catégories en fonction des informations, ou devrais-je avoir un seul tableau avec plusieurs colonnes?
Auparavant, je disposais de plusieurs tables, par exemple une table pour les données d'utilisation de l'application, une table pour les informations de profil, une table pour les jetons dorsaux, etc.
Récemment, quelqu'un m'a dit qu'il valait mieux ne pas le faire de cette façon et avoir une table avec beaucoup de colonnes, c'est bien. Le fait est que toutes ces colonnes ont la même clé primaire.
Je suis assez novice en matière de conception de base de données. Quelle approche est la meilleure et quels sont les avantages et les inconvénients?
Quelle est la manière conventionnelle de le faire?
Chaque fois que les informations sont uniques (chaque utilisateur a un nom et un mot de passe), il est probablement préférable de n'en avoir qu'une seule, car elle réduit le nombre de jointures nécessaires à la base de données pour extraire 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 inquiéterais pas dans des cas normaux, et vous pouvez toujours la scinder plus tard si vous en avez besoin.
Si les données sont un à plusieurs (chaque utilisateur a des milliers de lignes d'informations d'utilisation), il convient de les diviser en tables séparées afin de réduire les données en double (les données en double gaspillent de l'espace de stockage, de la mémoire cache et rendent la base de données plus difficile à gérer. ).
Vous pouvez trouver l'article Wikipedia sur normalisation de la base de données intéressant, car il en explique les raisons en profondeur:
La normalisation de base de données est le processus d'organisation des champs et des tables d'une base de données relationnelle afin de minimiser la redondance et la dépendance. 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 afin que les ajouts, les suppressions et les modifications d'un champ puissent être effectuées dans une seule table, puis propagées dans le reste de la base de données via les relations définies.
Dénormalisation doit également être pris en compte, car il est parfois préférable de répéter les données (car cela réduit la quantité de travail que la base de données doit effectuer lors de la lecture des données). Il est vivement recommandé de définir vos données de la manière la plus normalisée possible et de ne le dénormaliser que si vous êtes conscient des problèmes de performances rencontrés dans des requêtes spécifiques.
Une grande table est souvent un mauvais choix. Les tables associées sont celles avec lesquelles la base de données relationnelle a été conçue. Si vous indexez correctement et savez comment écrire des requêtes performantes, elles fonctionneront bien.
Lorsque les tables contiennent trop de colonnes, vous pouvez rencontrer des problèmes avec la taille réelle de la page sur laquelle la base de données stocke les informations. L’enregistrement risque de devenir trop volumineux pour la page, de sorte que vous risquez de ne plus pouvoir créer ou mettre à jour un enregistrement spécifique qui rend les utilisateurs mécontents, ou vous pouvez (du moins dans SQL Server) avoir un débordement pour Les types de données (avec un ensemble de règles que vous devez rechercher si vous le faites), mais si de nombreux enregistrements débordent de la taille de la page, vous pouvez créer de graves problèmes de performances. Maintenant, il vous faudra chercher dans la documentation de cette base de données comment MYSQL gère les pages et si vous avez un problème lorsque la taille potentielle de la page devient trop grande.
J'ai un bon exemple. Base de données excessivement normalisée avec l'ensemble de relations suivant:
people -> rel_p2staff -> staff
et
people -> rel_p2prosp -> prospects
Lorsque les personnes ont des noms et des détails de personnes, le personnel n'a que les détails des enregistrements de personnel, les perspectives ont uniquement des détails de perspectives, et les tables rel sont des tables de relations avec des clés étrangères provenant de personnes liant des personnes au personnel et aux perspectives.
Ce type de conception continue pour toute la base de données.
Maintenant, pour interroger cet ensemble de relations, il s’agit d’une jointure multi-tables à chaque fois, parfois 8 et plus. Cela a bien fonctionné jusqu’au milieu de cette année, quand il a commencé à devenir très lent maintenant que nous avons dépassé les 40000 enregistrements de personnes.
L'indexation et tous les fruits bas ont été utilisé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 refonte complète de l’application qui en dépend ainsi que la restructuration de la base de données, sur une période de 6 mois. $$$$ Aïe.
La solution sera d’avoir une relation directe pour people -> staff et people -> prospect
Je suis tombé sur ce problème et en tant que personne qui utilisait beaucoup MySQL, puis est passé récemment à Postgres, l'un des gros avantages est que vous pouvez ajouter des objets JSON à un champ dans Postgres.
Ainsi, si vous vous trouvez dans cette situation, vous ne devez pas nécessairement choisir entre une grande table avec plusieurs colonnes et la scinder, mais vous pouvez fusionner des colonnes dans des objets JSON pour la réduire, par exemple. au lieu d'une adresse de 5 colonnes, il ne peut s'agir que d'une seule. Vous pouvez également interroger sur cet objet aussi.
posez-vous ces questions si vous mettez tout dans une seule table, aurez-vous plusieurs lignes pour cet utilisateur? Si vous devez mettre à jour un utilisateur, souhaitez-vous conserver une trace d'audit? L'utilisateur peut-il avoir plus d'une instance d'un élément de données? (comme un numéro de téléphone par exemple) aurez-vous un cas où vous voudrez peut-être ajouter un élément ou un ensemble d'éléments ultérieurement? Si vous répondez oui, il est fort probable que vous souhaitiez des tables enfant avec des relations de clé étrangère.
Les avantages des tables parent/enfant sont l’intégrité des données, les performances via les index (oui, vous pouvez également le faire sur une table plate) et OMI plus facile à gérer si vous devez ajouter un champ ultérieurement, en particulier s’il s’agit d’un champ obligatoire.
Contre la conception est plus difficile, les requêtes deviennent légèrement plus complexes
Cependant, dans de nombreux cas, une grande table plate conviendra, vous devez donc examiner votre situation pour prendre une décision.
J'ai déjà fini de concevoir une base de données. pour moi, cela dépend de la difficulté du système à gérer les bases de données; Oui, il est vrai que les données uniques ne se trouvent qu’à un seul endroit, mais il est très difficile de faire des requêtes avec une base de données trop normalisée avec beaucoup d’enregistrements. Il suffit de combiner les deux schémas; utilisez une seule table si vous avez l’impression que vous aurez d’énormes disques difficiles à gérer, comme Facebook, Gmail, etc. et utiliser une table différente pour un jeu d’enregistrements pour un système simple ... eh bien, c’est tout simplement mon opinion .. j’espère que cela pourrait aider .. faites-le simplement ... vous pouvez le faire ... :)
La méthode conventionnelle consiste à utiliser différentes tables comme dans un schéma en étoile ou en flocon de neige. Howeevr, je baserais cette stratégie pour être double. Je crois en la théorie selon laquelle les données ne devraient exister qu’à un seul endroit, car le schéma que j’ai mentionné fonctionnerait bien. Cependant, je pense également que, pour les moteurs de reporting et les suites BI, une approche en colonnes serait extrêmement bénéfique, car elle répond davantage aux besoins de reporting. Les approches Columnar telles que celles avec infobright.org apportent des gains de performances et une compression énormes qui rendent l'utilisation des deux approches extrêmement utile. Beaucoup d'entreprises commencent à se rendre compte qu'une architecture de base de données unique ne répond pas à la totalité de leurs besoins. Beaucoup d’entreprises ont mis en œuvre le concept d’avoir plus d’une architecture de base de données.