MySQL: plusieurs tables ou une table avec beaucoup de colonnes?

Donc, c’est 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. Je suis inquiet si je devais diviser plusieurs tables en catégories en fonction des informations ou devrais-je avoir une seule table avec beaucoup de colonnes?

La façon dont je le faisais était d’avoir plusieurs tables, donc disons une table pour les données d’utilisation de l’application, une table pour les informations de profil, une table pour les jetons d’arrière-plan et etc. Récemment, on m’a dit qu’il valait mieux ne pas le faire et avoir une table avec beaucoup de colonnes, ça va. La chose 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 approche est la meilleure et quels sont les avantages et les inconvénients? Quelle est la manière conventionnelle de le faire?

Chaque fois qu’une information est un-à-un (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 firebase database doit 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 le diviser plus tard si nécessaire.

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 distinctes pour réduire les données en double (les données dupliquées gaspillent de l’espace de stockage et de la mémoire cache). ).

Vous trouverez peut-être intéressant l’article de Wikipédia sur la normalisation des bases de données , car il en explique les raisons en profondeur:

La normalisation de la firebase database consiste à organiser les champs et les tables d’une firebase database relationnelle afin de minimiser la redondance et la dépendance. La normalisation implique généralement de diviser les grands tableaux en tableaux plus petits (et moins redondants) et de définir les relations entre eux. L’objective est d’isoler les données afin que les ajouts, les suppressions et les modifications d’un champ puissent être effectués dans une seule table, puis propagés dans le rest de la firebase database via les relations définies.

La dénormalisation est également une chose dont il faut être conscient, car il y a des cas où la répétition des données est meilleure (car cela réduit la quantité de travail que la firebase database doit effectuer 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 connaissez des problèmes de performances dans des requêtes spécifiques.

Une grande table est souvent un mauvais choix. Les tables connexes sont ce que la firebase database relationnelle a été conçue pour fonctionner. Si vous indexez correctement et savez écrire des requêtes performantes, elles vont fonctionner 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 firebase database stocke les informations. Soit le dossier peut finir par être trop volumineux pour la page, dans lequel pouvez-vous finir par ne pas pouvoir créer ou mettre à jour un enregistrement spécifique qui rend les utilisateurs mécontents ou vous pouvez (dans SQL Server au moins) 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 des problèmes de performances considérables. Maintenant, comment MYSQL gère les pages et si vous avez un problème lorsque la taille potentielle de la page devient trop grande est quelque chose que vous devez rechercher dans la documentation de cette firebase database.

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, voulez-vous conserver une piste d’audit? L’utilisateur peut-il avoir plusieurs instances d’un élément de données? (comme le numéro de téléphone par exemple) aurez-vous un cas où vous pourriez vouloir append un élément ou un ensemble d’éléments plus tard? Si vous répondez oui, il est fort probable que vous souhaitiez 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 des index (oui, vous pouvez également le faire sur une table plate) et la maintenance IMO plus facile si vous devez append un champ ultérieurement, surtout s’il s’agit d’un champ obligatoire.

Par contre, la conception est plus difficile, les requêtes deviennent légèrement plus complexes

Mais, il y a beaucoup de cas où une grande table plate sera appropriée, donc vous devez regarder votre situation pour décider.

J’ai un bon exemple. Base de données trop normalisée avec les relations suivantes:

people -> rel_p2staff -> staff 

et

 people -> rel_p2prosp -> prospects 

Lorsque les personnes ont des noms et des informations sur les personnes, le personnel ne dispose que des détails du dossier du personnel, des informations sur les prospects uniquement et les tables des relations sont des tables de relations avec des personnes étrangères.

Ce type de conception se poursuit pour toute la firebase database.

Maintenant, pour interroger cet ensemble de relations, il s’agit d’une jointure multi-table à chaque fois, parfois même plus de 8 jointures de table. 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é 40000 enregistrements de personnes.

L’indexation et tous les fruits à scope de main avaient été épuisés l’an dernier, toutes les requêtes sont optimisées à la perfection. Ceci est la fin de la route pour la conception normalisée particulière et la gestion maintenant approuvé une reconstruction complète de l’application qui en dépend, ainsi que la restructuration de la firebase database, sur une durée de 6 mois. $$$$ Aïe.

La solution sera d’avoir une relation directe pour les people -> staff et les people -> prospect

J’ai déjà fait une conception de firebase database. pour moi, cela dépend de la difficulté du système avec la gestion de la firebase database; Oui, il est vrai que des données uniques sont disponibles à un seul endroit, mais il est très difficile de faire des requêtes avec une firebase database trop normalisée avec beaucoup d’enregistrements. Il suffit de combiner les deux schémas; utilisez un grand tableau si vous sentez que vous aurez des disques massifs 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 juste mon avis .. j’espère que ça pourrait aider .. il suffit de le faire..vous pouvez le faire … 🙂

La méthode conventionnelle consiste à utiliser différentes tables comme dans un schéma en écanvas ou en flocon. Cependant, je baserais cette stratégie sur deux. Je crois en la théorie que les données ne devraient exister que dans un seul endroit, là pour le schéma que j’ai mentionné fonctionnerait bien. Cependant, je pense également que pour les moteurs de reporting et les suites de veille économique, une approche en colonnes serait extrêmement bénéfique, car elle répond davantage aux besoins de reporting. Les approches à colonnes comme celles avec infobright.org ont des gains de performance et une compression énormes, ce qui rend l’utilisation des deux approches extrêmement utile. Beaucoup d’entresockets commencent à se rendre compte qu’une seule architecture de firebase database au sein de l’organisation ne répond pas à tous leurs besoins. De nombreuses entresockets mettent en œuvre le concept d’avoir plusieurs architectures de bases de données.

Entré en travers de ceci, et en tant que quelqu’un qui utilisait beaucoup MySQL, et est passé récemment à Postgres, un des grands avantages est que vous pouvez append des objects JSON à un champ dans Postgres.

Donc, si vous êtes dans cette situation, vous ne devez pas nécessairement choisir entre une grande table avec beaucoup de colonnes et la diviser, mais vous pouvez fusionner des colonnes en objects JSON pour la réduire, par exemple, au lieu de 5 colonnes. être une. Vous pouvez également interroger sur cet object également.

Je pense qu’il est plus efficace d’avoir un tableau unique, 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 indique l’âge et les notes des élèves, vous devez organiser le tableau de manière à ce que le meilleur marqueur soit bien différencié du meilleur marqueur et que la différence d’âge des élèves soit égale.