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

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.

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.

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 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.

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) .

É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.)

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.

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.

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.

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.

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.

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".

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.

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.