MySQL: plusieurs tables ou une table avec plusieurs colonnes?

C'est donc plus 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.

Dois-je avoir plusieurs tableaux divisés en catégories selon les informations, ou devrais-je avoir un seul tableau avec plusieurs colonnes?

La façon dont je le faisais était d'avoir plusieurs tables, disons, une table pour les données d'utilisation des applications, une table pour les informations de profil, une table pour les jetons back-end, etc. pour garder les choses organisées.

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 nouveau dans la conception de bases de données, alors 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 individuelles (chaque utilisateur a un nom et un mot de passe), il est probablement préférable de disposer d'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'inquiéterais pas à ce sujet dans les cas normaux, et vous pouvez toujours le diviser 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), elles doivent être divisées en tables séparées pour 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 trouverez peut-être l'article de Wikipedia sur la normalisation des bases de données intéressant, car il en discute en profondeur les raisons:

La normalisation de la base de données est le processus d'organisation des champs et des tables d'une base de données relationnelle pour minimiser la redondance et la dépendance. La normalisation implique généralement de diviser les grandes tables en tables plus petites (et moins redondantes) et de définir les relations entre elles. L'objectif est d'isoler les données afin que les ajouts, suppressions et modifications d'un champ puissent être effectués dans une seule table, puis propagés dans le reste de la base de données via les relations définies.

La dénormalisation est également une chose à prendre en compte, car il y a 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 faire lors de la lecture des données). Je vous recommande vivement de rendre vos données aussi normalisées que possible pour commencer et de ne les dénormaliser que si vous êtes conscient de problèmes de performances 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 correctement.

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. Soit l'enregistrement peut finir par être trop volumineux pour la page, ce qui peut vous empêcher de créer ou de mettre à jour un enregistrement spécifique qui rend les utilisateurs mécontents, soit vous pouvez (au moins dans SQL Server) être autorisé à un débordement pour certains types de données (avec un ensemble de règles que vous devez rechercher si vous faites cela) mais si de nombreux enregistrements dépassent la taille de la page, vous pouvez créer de graves problèmes de performances. Maintenant, comment MYSQL gère les pages et si vous avez un problème lorsque la taille potentielle de la page devient trop grande, vous devrez rechercher dans la documentation de cette base de données.

J'ai un bon exemple. Base de données trop 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 sur les personnes, le personnel n'a que les détails de l'enregistrement du personnel, les prospects n'ont que les détails des prospects, et les tables rel sont des tables de relations avec des clés étrangères de personnes reliant le personnel et les prospects.

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

Maintenant, pour interroger cet ensemble de relations, c'est une jointure multi-table à chaque fois, parfois 8 jointures de table 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é les 40000 records de personnes.

L'indexation et tous les fruits à portée de main avaient été utilisés l'année dernière, toutes les requêtes sont optimisées à la perfection. C'est la fin du chemin pour la conception normalisée particulière et la gestion approuvée maintenant une reconstruction de l'application entière qui en dépend ainsi que la restructuration de la base de données, sur une durée de 6 mois. $$$$ Aïe.

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

Je suis tombé sur cela, et en tant que personne qui utilisait beaucoup MySQL, puis qui est passé récemment à Postgres, l'un des grands avantages est que vous pouvez ajouter des objets JSON à un champ dans Postgres.

Donc, si vous êtes dans cette situation, vous ne devez pas nécessairement choisir entre une grande table avec plusieurs colonnes et la diviser, mais vous pouvez fusionner des colonnes en objets JSON pour le réduire, par exemple au lieu que l'adresse soit de 5 colonnes, cela peut simplement être une. Vous pouvez également interroger cet objet.

posez-vous ces questions si vous mettez tout dans une table, aurez-vous plusieurs lignes pour cet utilisateur? Si vous devez mettre à jour un utilisateur, souhaitez-vous conserver une piste d'audit? 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) aurez-vous un cas où vous voudrez peut-être ajouter un élément ou un ensemble d'éléments plus tard? si vous répondez oui, vous souhaiterez probablement avoir des tables enfants 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 le faire sur une table plate également) et l'OMI plus facile à maintenir si vous devez ajouter un champ plus tard, surtout si ce sera un champ obligatoire.

La conception des inconvénients est plus difficile, les requêtes deviennent légèrement plus complexes

Mais, dans de nombreux cas, une grande table plate conviendra, vous devez donc examiner votre situation pour décider.

J'ai déjà fait une sorte de conception de base de données. pour moi, cela dépend de la difficulté du système avec la gestion de la base de données; oui, il est vrai d'avoir des données uniques en 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 difficiles à maintenir, tout comme Facebook, Gmail, etc. et utiliser une table différente pour un jeu d'enregistrements pour un système simple ... eh bien c'est juste mon avis .. j'espère que cela pourrait aider .. faites-le ... vous pouvez le faire ... :)

La manière conventionnelle de le faire serait d'utiliser des tables différentes comme dans un schéma en étoile ou un schéma en flocon de neige. Cependant, je baserais cette stratégie sur deux volets. 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 en colonnes comme celles avec infobright.org ont d'énormes gains de performances et de compression qui rendent l'utilisation des deux approches extrêmement utile. De nombreuses entreprises commencent à se rendre compte qu'une seule architecture de base de données dans l'organisation ne répond pas à l'ensemble de leurs besoins. De nombreuses entreprises mettent en œuvre à la fois le concept d'avoir plus d'une architecture de base de données.

Je pense qu'avoir un seul tableau est plus efficace, mais vous devez vous assurer que le tableau est organisé de manière à montrer la relation, la tendance ainsi que la différence entre les variables d'une même ligne. par exemple, si le tableau montre l'âge et les notes des élèves, vous devez le disposer de manière à ce que le meilleur score soit bien différencié avec le score le plus bas et que la différence d'âge des élèves soit égale.