Est-il nécessaire de créer une base de données avec le moins de tables possible

52

Devrions-nous créer une structure de base de données avec un nombre minimum de tables?

Devrait-il être conçu de manière à ce que tout reste au même endroit ou est-il acceptable d'avoir plus de tables?

Cela affectera-t-il quoi que ce soit?

Je pose cette question parce qu'un de mes amis a modifié une structure de base de données dans mediaWiki. En fin de compte, au lieu de 20 tables, il n’en utilisait que 8, et il lui a fallu 8 mois pour le faire (c’était sa mission au collège).

MODIFIER

Je conclus la réponse comme suit: la taille des tables importe peu, jusqu'à ce que le cas soit exceptionnel; auquel cas la dénormalisation peut aider.

Merci à tous pour les réponses.

Shaheer
la source
15
Le nombre minimum de tables est facile, il suffit de sérialiser le tout en maître_table (nom_table, nom_col, type_col, type_ligne, valeur).
Inca
quelle? je ne
comprends
12
Étant donné que chaque champ d'une base de données est défini par la combinaison du nom de la table, du nom de la colonne, de la clé primaire et de la valeur, vous pouvez toujours réduire le nombre de tables en les dénormalisant dans une table unique. Pas très utile, mais tout à fait possible.
Inca
Eh bien, je demandais pour savoir, et si quelque chose est moins utile que l'existant, pourquoi ne pas changer? Je veux dire que cela apportera-t-il quelque amélioration la performance par exemple?
Shaheer
1
@Hamza: Cela pourrait améliorer les performances. Cela dépend vraiment des circonstances spécifiques. Il n'y a pas presque suffisamment d' informations pour nous de fournir une réponse concrète.
FrustratedWithFormsDesigner

Réponses:

155

IGNOREZ le nombre de tables. Vous inquiétez plus pour obtenir la conception correcte. Si votre principale préoccupation est la quantité de tables, vous ne devriez probablement pas concevoir de systèmes de base de données.

Si votre ami avait seulement besoin de 8 tables et que le système fonctionne bien avec cela, alors 8 est le nombre correct, et les 12 autres pourraient ne pas être nécessaires pour quoi que ce soit qu'il faisait.

Les exceptions possibles sont peut-être des environnements particuliers qui imposent des limites strictes au nombre de tableaux, mais je ne peux pas penser à un exemple concret d'un tel système à mon sens.

FrustratedWithFormsDesigner
la source
107
+1:If your major concern is quantity of tables, you should probably not be designing database systems.
Joel Etherton le
9
Corollaire: une table de base de données ne prend pas [beaucoup] d'espace supplémentaire. Ce sont les données qui prennent de la place. Normalisation = plus de tables = moins de répétition = moins d'espace utilisé. En essayant de minimiser le nombre de tables, vous compromettez non seulement la conception, mais vous perdez de la place . Ce "table de golf" est tout simplement mauvais, à moins que certaines des tables ne soient littéralement redondantes.
Aaronaught
1
+1, bien que je ne pense pas que nous en sachions assez pour dire que le nombre correct est 8 dans son cas, car nous ne pouvons pas comparer les schémas (l'original pourrait mieux résister à un volume transactionnel plus élevé que celui de l'application exemple)
Adam Robinson
2
@Hamza: D'accord, il a peut-être de bonnes compétences en PHP et en bases de données, et ce projet peut nécessiter les deux, mais ne présumez pas que l'un implique automatiquement l'autre. De nombreux développeurs peuvent avoir une compétence mais pas l’autre.
FrustratedWithFormsDesigner
4
@Tom Anderson - Alors vous ne devriez toujours pas concevoir de systèmes de base de données.
Joel Etherton
71

Une base de données doit avoir exactement autant de tables que nécessaire. Pas moins, pas plus.

Adam Crossland
la source
3
english.stackexchange.com/questions/495/less-vs-fewer Il ne s'agit pas de transformer cette discussion en une discussion, mais voici une discussion intéressante sur le débat "moins" ou "moins", y compris ses origines, de la langue anglaise SE , car il semble vous enthousiasmer les gars;)
Corey
17

Les tables de base de données doivent adhérer au principe de responsabilité unique, tout comme les classes. Chaque table ne doit pas traiter plus d’un groupe de données liées. La performance mise à part, cela rend la bête plus facile à gérer, car les tables elles-mêmes seront plus petites. Cela vous donne également de meilleures performances, car les tables plus petites sont plus rapides à rechercher et à joindre.

Ne vous inquiétez pas plus du nombre de tables que du nombre de classes, ne vous inquiétez pas du tout. Concentrez-vous sur la création d'un code correct, propre et lisible, et non sur la quantité d'espace qu'il prend. Refactoriser de manière agressive une fois que vous avez un produit fonctionnel pour le rendre meilleur - et je parle aussi de la base de données! Vous verrez des colonnes qui devraient figurer dans d'autres tables ou qui ne sont pas nécessaires, etc. Profil pour voir quelles requêtes prennent le plus de temps et pourquoi, et résoudre ces problèmes s'ils posent vraiment problème.

Michael K
la source
4
Dans un modèle de données normalisé, oui, il s'agit de la meilleure approche. Toutefois, si la base de données est destinée à la création de rapports ou principalement à l'accès en lecture, les tables "aplaties" dénormalisées fonctionneront mieux avec de grands ensembles de données. Dans ce cas, un nombre réduit de tables entraînera moins de jointures et de meilleures performances.
maple_shaft
2
@ maple Absolument d'accord. Vous devez définir un profil pour déterminer quels ensembles de données doivent être groupés. IMO vous devez donc commencer normalisé. YMMV, les experts peuvent probablement le faire spontanément :) Jeff a aussi un article sur la dénormalisation que vous pourriez trouver intéressant.
Michael K
1
Bon et succint après, j'ai déjà lu celui-ci! Parfois, vous pouvez tirer parti du meilleur des deux mondes. Si la création de rapports n'a pas besoin d'être à 100% en temps réel, maintenez deux schémas, l'un principal étant le schéma normalisé transactionnel destiné à être utilisé par les applications, l'autre étant un schéma dénormalisé régulièrement diffusé et adapté à la création de rapports sur l'accès aux données.
maple_shaft
1
Plus d'informations sur le sujet avec une explication du schéma en étoile: publib.boulder.ibm.com/infocenter/rbhelp/v6r3/…
maple_shaft
1
@maple_shaft, je conviens que les bases de données de création de rapports sont souvent dénormalisées en termes de performances, mais ce n'est pas quelque chose que je m'attendrais à ce qu'un étudiant ou un programmeur débutant soit autorisé à prendre en charge. Je sais que je ne tolérerais certainement pas que mes entrepôts de données soient gérés par des personnes qui ne possèdent pas une expertise reconnue.
HLGEM
7

Une base de données de production pour une application métier peut contenir des centaines voire des milliers de tables. Vous avez besoin du nombre de tables dont vous avez besoin pour répondre aux besoins de votre entreprise. Essayer de réduire le nombre de tables simplement pour avoir moins de tables aura généralement pour résultat une base de données plus difficile à interroger, présentant des problèmes d'intégrité des données et beaucoup plus difficile à maintenir qu'une base de données normalisée.

Il y a des moments où la dénormalisation est nécessaire. Cela ne devrait être fait que par quelqu'un qui sait exactement ce qu'il / elle fait et pourquoi. Il est très facile de faire de la dénomalisation. Cela ne devrait donc être fait que par un spécialiste de la base de données ou un développeur d'applications expérimenté avec des années d'expérience dans la base de données. Une personne inexpérimentée devrait s'efforcer, au minimum, d'atteindre la troisième forme normale (à moins que vous ne fassiez l'entreposage de données, domaine dans lequel je n'envisagerais pas l'embauche d'une personne inexpérimentée) dans la base de données qu'il conçoit.

Quand les gens disent réduire les tables parce que les jointures sont coûteuses, ils sont généralement ignorants ou ont des bases de données mal conçues qui manquent d'index critiques ou utilisent de grandes clés naturelles mulit-column. Les bases de données relationnelles sont conçues pour utiliser des jointures et les jointures peuvent être assez efficaces si les FK sont correctement indexés et utilisent de petits champs pour se joindre (les entiers sont les plus efficaces). Vous remarquerez que les grandes entreprises qui possèdent des bases de données de la taille d'un terrabyte parviennent à obtenir d'excellentes performances et à utiliser des jointures.

Aucun concepteur de base de données sérieux n'essaie jamais de réduire le nombre de tables simplement parce qu'il veut moins de tables. Vous réduisez le nombre de tables car les données ne sont plus nécessaires ou vous avez un problème de performances que vous ne pouvez pas résoudre autrement (et il existe de nombreuses façons d'essayer avant de prendre en charge le risque considérable que représente la dénormalisation d'une table pour vos données) .

HLGEM
la source
BigTable a été conçu par Google et a délibérément exclu les jointures, car il n’est pas parallélisable.
Lie Ryan
2
@Lie Ryan, BigTable est un cas spécial qui ne convient PAS à la plupart des applications d'entreprise car l'intégrité des données n'est pas une préoccupation majeure. Google n'a pas besoin de très nombreuses règles commerciales complexes pour la recherche. Je parierais que leur application financière d'entreprise n'utilise pas BigTable. Néanmoins, la plupart des applications métier disposant de bases de données volumineuses peuvent en fait utiliser des jointures et exécuter leurs tâches correctement si le concepteur est compétent. Les bases de données d'entreprise ont de nombreux moyens d'améliorer les performances (y compris le partitionnement) et n'ont donc pas besoin de perdre les fonctionnalités d'intégrité des données d'une base de données relationnelle.
HLGEM
+1 pour vous, @HLGEM, à la fois pour la réponse et le commentaire; C'est vraiment dommage de voir de nombreux développeurs se lancer dans le mouvement de la base de données de documents parce qu'ils pensent que "rejoint = lent", seulement pour tenter de résoudre les problèmes relationnels résolus par les bases de données relationnelles il y a 20 ans.
Adam Robinson
5

Étant donné que chaque champ d'une base de données est défini par la combinaison du nom de la table, du nom de la colonne, de la clé primaire et de la valeur, vous pouvez toujours réduire le nombre de tables en les dénormalisant dans une table unique. Pas très utile, mais tout à fait possible.

Les tableaux sont une couche abstraite qui facilite le traitement des données. C'est pourquoi ils sont créés. J'en ai fait une blague, mais comprendre que vous pouvez réduire chaque ensemble de données à un seul tableau maître montre immédiatement pourquoi vous ne devriez pas: parce que les tableaux vous apportent quelque chose. Sur le plan conceptuel, ils vous apportent une structure plus facile à comprendre pour les humains que les données sérialisées. Au niveau intermédiaire, ils apportent le concept de normalisation: éviter de sauvegarder des données redondantes et donner un point unique pour les modifications, plutôt que de changer quelque chose à plusieurs endroits. Sur le plan technique, les bases de données contiennent la plupart des tâches que vous voulez faire avec des données, de nombreux outils, et les ont implémentées et testées plus que vous ne le ferez probablement vous-même. Pensez aux types de données, aux valeurs par défaut, aux droits des utilisateurs, aux index, aux contraintes de clé étrangère, etc. Il a été testé, utilisé par beaucoup, optimisé, débogué. (Pas à la perfection, mais quand même.)

Puisqu'une base de données est un outil, le principal est de décider de son utilisation. Le nombre de tables n'est pas important. Minimiser est toujours possible, mais au détriment des avantages. (Si vous en lisez plus sur la normalisation, vous rencontrerez les quelques cas de dénormalisation - mais même dans ce cas, il s'agit de prendre les bonnes décisions plutôt que de réduire aveuglément le nombre de tables.)

Inca
la source
merci, il est beaucoup plus clair maintenant !, et j'ai lu sur la normalisation BTW, je le fais même dans des bases de données CakePHP, ce qui favorise une autre et quelque peu différente approche.
Shaheer
3

Vous devez utiliser le bon nombre de tables. Vous pouvez théoriquement vous contenter d'une table unique en dénormalisant l'ensemble de la base de données, mais celle-ci serait inutilisable. Ton ami a l’air d’avoir trop de temps libre.

Neil Butterworth
la source
2

Avoir le nombre minimum de tables me semble être un objectif très particulier.

Certes, réduire un schéma de 20 tables à 8 pourrait être une bonne chose (si cela est bien fait, cela pourrait réduire les jointures et augmenter les performances, supprimer les colonnes inutilisées, etc.), mais cela pourrait également rendre plus difficile la compréhension et l'amélioration.

Pour y penser autrement, pensez-vous que la normalisation est une bonne chose? La normalisation entraîne généralement un plus grand nombre de tables, mais également des solutions plus faciles à gérer, une duplication réduite des données et une gestion plus facile des données.

Bien sûr, cela peut également entraîner des performances plus lentes (en supposant que la base de données dénormalisée soit bien conçue).

En fin de compte, vous devez déterminer quelles sont vos exigences dans ces domaines, mais comme position de départ par défaut, je vous conseille d’atteindre un niveau de normalisation raisonnable, puis de voir si cela pose problème, pour lequel moins de tables pourraient constituer une solution.

Jon Hopkins
la source
0

Le nombre n'est pas important. Le design est. Regardez quelques systèmes là-bas. Magento, PHPBB, etc. Ils ont des dizaines de tables dans leurs systèmes et fonctionnent parfaitement.

Ryan Street
la source
0

Outre les problèmes de normalisation et de performances, vous pouvez utiliser "qui nécessitera une autre table" pour gérer l'étendue d'une application. Cette fonctionnalité nécessitera une nouvelle table et tout le temps, l'énergie et les efforts nécessaires pour concevoir, construire, tester, gérer les mises à niveau et tous les autres codes impliqués. L'ajout de 5 champs à une ou plusieurs tables existantes (le cas échéant) est beaucoup plus simple qu'une table à 5 colonnes.

JeffO
la source
0

Si vous concevez une base de données en essayant de minimiser la création de tables, vous verrez rapidement la difficulté et vous tromper.

Le nombre de tables ne doit pas être à l’avant-plan de votre esprit lorsque vous créez une conception de base de données. Placez les objets là où ils doivent aller logiquement et relationnellement.


la source
0

Je pense que le nombre de tables est important et peut avoir un impact important sur les performances si vous choisissez de fractionner des données qui doivent, pour toutes les intentions et objectifs de l'entreprise, rester ensemble, en plusieurs tables (afin de disposer d'une base de données de normalisation). Habituellement, lorsque vous effectuez cette opération, vous devez forcer l'opération JOIN (ou son équivalent non-SQL) afin d'obtenir toutes les données dont vous avez besoin et pour des tables suffisamment grandes, ainsi structurées, les performances s'enlisent rapidement.

Je ne vais pas entrer dans les détails, mais je pense que le fait réel que le nombre de tables peut influer sur les performances est l'une des raisons pour lesquelles aucune base de données SQL, telle que Cassandra, Mongo et Google BigTable (sic!) N'a été inventée. et c’est aussi pour cette raison qu’ils encouragent la normalisation des données (et évitent ainsi le grand nombre de tables / collections, etc.).

On pourrait en dire autant des serveurs de recherche tels que Apache's Solr, qui n'encouragent pas ou ne facilitent pas facilement la division de vos documents en plusieurs "tableaux" ou "types d'entrées", ce qui vous encourage à utiliser un schéma "un englobe tous" comportant des champs communs. à tous les types de documents que vous souhaitez indexer (et par conséquent, évitez de faire des opérations de type JOIN).

Je ne dis pas que le simple fait d'avoir x tables dans un schéma le rendra nécessairement plus lent qu'un schéma avec x / 2 tables tout le temps, mais il existe certains contextes dans lesquels cela peut entraîner des ralentissements dus à des conséquences opérations supplémentaires nécessaires pour agréger les données dans toutes ces tables. En continuant sur ce point, je ne pense pas non plus qu'il soit acceptable de dire "un nombre quelconque de tables et une normalisation extrême des données n'a aucun impact sur les performances".

Shivan Dragon
la source
0

Oncle Bob soutiendrait que More is Simpler.

Voir http://c2.com/cgi/wiki?FearOfAddingTables

"une bonne conception est généralement simplifiée en ajoutant des tables"

Je crois que presque toutes les entités sont nombreuses, ce qui nécessite davantage de tables.

Créez une table de pays avec le code de continent qui s'y trouve. Oh, vous ne pouvez pas, car il y a actuellement 8 pays transcontinentaux. Même avec les devises. Le Panama en utilise deux.

Neil McGuigan
la source
-2

Alors la réponse est oui.

Mais dépend de la véritable signification du nombre "minimum" de tables.

Par exemple (un anti-exemple).

Si j'ai les objets suivants

  1. utilisateurs
  2. les clients

et les deux partagent les mêmes états (champs) et il n'y a pas de restriction de sécurité alors, il est plus approprié de faire une seule table

  1. personnes_table

plutôt deux tables différentes

  1. utilisateurs_table
  2. clients_table

le contre est que dans les table_persons nous devrons ajouter un nouveau champ (type_of_person).

Une autre erreur (erreur si cela n’est pas vraiment nécessaire) est de "diviser" une table, comme suit: séparez une seule table en deux.

  1. personnes_table

en deux tables

  1. table_info_persons
  2. table_extra_info_persons

parce que vous obligez certaines requêtes à joindre deux tables et que c'est mauvais.

Magallanes
la source
hé ta réponse est très descriptive et
utile
2
Cela me donne des flashbacks sur ma première application d'entreprise et sur la base de données qui la sous-tend et sur le cauchemar que le DBA a créé pour devenir un nazi de table sur des sujets comme celui-ci. Je ne voudrais absolument jamais coller clients et utilisateurs ensemble, ce sont des entités commerciales totalement disparates.
-1: Les utilisateurs et les clients ont des champs différents; Si ce n'est pas le cas pour le moment, ils l'auront à l'avenir. Ils méritent donc des tables séparées.
Sjoerd
1
@Sjoerd, @Chris: Bien que cela puisse souvent être le cas, ce n'est pas nécessairement vrai. Ce genre de chose dépend de l'application. Cela étant dit, je suis d'accord avec le sentiment. Trop souvent, les développeurs de base de données verront que "noms de champs communs" signifie qu'il s'agit des mêmes données. Cela devient particulièrement facile à faire lorsque vous examinez d'abord la base de données à partir de l'ORM (autrement dit, à l'envers). Bien que les concepts OO puissent être modélisés dans la base de données, les bases de données sont des lignes et des relations et non des objets .
Adam Robinson
1
+1 pour "les bases de données sont des lignes et des relations, pas des objets", je l'ajouterai à mes citations préférées!
Shaheer