Est-il nécessaire de créer une base de données avec le moins de tables possible
Faut-il créer une structure de base de données avec un nombre minimum de tables?
Doit-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 de quelque façon que ce soit?
Je pose cette question parce qu'un de mes amis a modifié une structure de base de données dans mediaWiki. Au final, au lieu de 20 tables, il n'en utilisait que 8, et il lui a fallu 8 mois pour le faire (c'était son affectation au collège).
MODIFIER
Je conclus la réponse comme suit: la taille des tables n'a pas d'importance, jusqu'à ce que le cas soit exceptionnel; auquel cas la dénormalisation peut aider.
Merci à tous pour les réponses.
IGNORE le nombre de tables. Inquiétez-vous davantage d'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 n'avait besoin que de 8 tables et que le système fonctionne correctement avec cela, alors 8 est le nombre correct, et les 12 restants pourraient ne pas être nécessaires pour quoi qu'il fasse.
Les exceptions possibles pourraient être des environnements particuliers qui ont des limites strictes sur les numéros de table, mais je ne peux pas penser à un exemple concret d'un tel système sur le dessus de ma tête.
Une base de données doit avoir exactement autant de tables que nécessaire. Pas moins, pas plus.
Les tables de base de données doivent adhérer au principe de responsabilité unique, tout comme les classes. Chaque tableau ne doit pas traiter plus d'un groupe de données connexes pour commencer. Mis à part les performances, cela facilite la gestion de la bête, 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 propre, propre et lisible, pas sur la quantité d'espace qu'il contient reprend. Refactorisez agressivement 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 être 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 sont vraiment un problème.
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 les besoins de l'entreprise. Essayer de réduire le nombre de tables juste pour avoir moins de tables entraînera généralement une base de données plus difficile à interroger, 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 une personne qui sait exactement ce qu'elle fait et pourquoi. Il est très facile de nettoyer la dénomalisation, donc cela ne devrait être fait que par un spécialiste de base de données ou un développeur d'applications senior 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 le troisième formulaire normal (à moins que vous ne fassiez de l'entreposage de données, un domaine pour lequel je n'envisagerais pas d'embaucher une personne inexpérimentée) dans n'importe quelle base de données qu'elle conçoit.
Lorsque les gens disent réduire les tables parce que les jointures sont chères, 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 à plusieurs colonnes. 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 connecter (les entiers sont les plus efficaces). Vous remarquerez que les grandes entreprises qui ont des bases de données de taille terrabyte parviennent en quelque sorte à 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 le risque étend to vos données de dénormalisation d'une table).
É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 en une seule table qui stocke exactement cela. Pas très utile, mais tout à fait possible.
Les tableaux sont une couche abstraite qui aide à résoudre les problèmes de 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 à une seule table principale souligne immédiatement pourquoi vous ne devriez pas: parce que les tables 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: pour éviter de sauvegarder des données redondantes et donner un point unique pour les changements, plutôt que de changer quelque chose à plusieurs endroits. Au niveau technique, les bases de données apportent la plupart des choses que vous voulez faire avec les données, de nombreux outils, et les ont implémentées et testées plus que vous ne le feriez probablement par vous-même. Pensez aux types de données, aux valeurs par défaut, aux droits d'utilisateur, aux indices, aux contraintes de clé étrangère, etc. Il a été testé, utilisé par beaucoup, optimisé, débogué. (Pas dans la perfection, mais quand même.)
Puisqu'une base de données est un outil, l'essentiel est de décider comment utiliser l'outil. Le nombre de tables n'est pas important. La minimisation est toujours possible mais au prix de retirer les avantages. (Si vous lisez plus sur la normalisation, vous rencontrerez les quelques cas de dénormalisation - mais même alors, il s'agit des décisions à droite plutôt que de simplement réduire aveuglément le nombre de tables.)
Vous devez utiliser le nombre de tables à droite. En théorie, vous pourriez vous contenter d'une table unique en dénormalisant la base de données entière, mais la base de données serait inutilisable. Votre ami sonne comme s'il avait trop de temps sur les mains.
Avoir le nombre minimum de tables me semble être un objectif très particulier.
Réduire un schéma de 20 tables à 8 pourrait certainement être une bonne chose (s'il est bien fait, cela pourrait réduire les jointures et augmenter les performances, supprimer les colonnes inutilisées, etc.), mais cela pourrait également le rendre plus difficile à comprendre et à améliorer à l'avenir.
Pour y penser autrement, pensez-vous que la normalisation est une bonne chose? La normalisation conduit généralement à un plus grand nombre de tables mais également à des solutions plus maintenables, à une duplication des données réduite et à une gestion des données plus facile.
Bien sûr, cela peut également entraîner un ralentissement des performances (en supposant que la base de données dénormalisée était bien conçue).
En fin de compte, vous devez réfléchir à vos besoins dans ces domaines, mais en tant que position de départ par défaut, je dirais opter pour un niveau de normalisation raisonnable, puis vérifier si cela pose des problèmes spécifiques où moins de tables pourraient être une solution.
Je pense que le nombre de tables est important et peut avoir un grand impact sur les performances si vous choisissez de diviser les données qui devraient, à toutes fins utiles, rester ensemble, en plusieurs tables (c'est-à-dire que vous auriez une base de données de normalisation). Habituellement, lorsque vous faites cela, vous serez obligé de rejoindre JOIN Operations (ou un équivalent non SQL) afin d'obtenir toutes les données dont vous avez besoin et pour des tables suffisamment grandes structurées comme ceci, les performances baissent rapidement.
Je ne vais pas entrer dans les détails, mais je pense que le fait bien réel que le nombre de tables puisse influencer les performances est l'une des raisons pour lesquelles des bases de données noSQL telles que Cassandra, Mongo et Google BigTable (sic!) Ont été inventées, et c'est aussi pourquoi ils encouragent la dénormalisation des données (et par conséquent en évitant un grand nombre de tables/collections, etc.).
La même chose pourrait être dite pour les serveurs de recherche tels que le Solr d'Apache qui n'encourage pas vraiment ou ne facilite pas facilement la division de vos documents en plusieurs "tables" ou "types d'entrées" vous encourageant à la place à avoir un schéma "un englobe tout" qui a des champs communs à tous les types de documents que vous souhaitez indexer (et évitez par conséquent d'avoir à effectuer 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 des tables x/2 tout le temps, mais il existe certains contextes dans lesquels cela peut conduire à des ralentissements dus à des opérations supplémentaires nécessaires pour agréger les données dans toutes ces tables. Poursuivant sur ce point, je ne pense pas non plus qu'il soit correct de dire "un nombre illimité de tableaux et une normalisation extrême des données n'ont aucun impact sur les performances".
Outre les problèmes de normalisation et de performances, vous pouvez utiliser "qui nécessitera une autre table" comme moyen de gérer la portée 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 codages impliqués. L'ajout de 5 champs aux tables existantes (le cas échéant) est beaucoup plus facile qu'une table à 5 colonnes.
Si vous concevez une base de données en essayant de minimiser la création de table, vous verrez bientôt la difficulté abrupte et vous vous tromperez.
Le nombre de tables ne doit pas être au premier plan de votre esprit lors de la création d'une conception de base de données. Mettez les choses là où elles doivent aller logiquement et relationnellement.
L'oncle Bob dirait que Plus est plus simple.
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 plusieurs-à-plusieurs, ce qui nécessite plus de tables.
Créez un tableau des pays avec le code du continent. Oh, vous ne pouvez pas parce qu'il y a en fait 8 pays transcontinentaux. Même chose avec les devises. Le Panama en utilise deux.
Le nombre n'est pas important. Le design est. Regardez certains systèmes. Magento, PHPBB, etc. Ils ont des dizaines de tables dans leurs systèmes et fonctionnent très bien.