Quelle est la meilleure conception de base de données :plus de tableaux ou plus de colonnes ?[fermé]

Question

Un ancien collègue a insisté sur le fait qu'une base de données avec plus de tables avec moins de colonnes chacune est meilleure qu'une base de données avec moins de tables avec plus de colonnes chacune.Par exemple plutôt qu'une table client avec nom, adresse, ville, état, code postal, etc.colonnes, vous auriez une table de noms, une table d'adresses, une table de villes, etc.

Il a fait valoir que cette conception était plus efficace et plus flexible.C'est peut-être plus flexible, mais je ne suis pas qualifié pour me prononcer sur son efficacité.Même si c’est plus efficace, je pense que ces gains pourraient être contrebalancés par la complexité supplémentaire.

Alors, y a-t-il des avantages significatifs à avoir davantage de tables avec moins de colonnes par rapport à moins de tables avec plus de colonnes ?

Answer 1

J'ai quelques règles empiriques assez simples que je suis lors de la conception de bases de données, qui, je pense, peuvent être utilisées pour aider à prendre des décisions comme celle-ci....

1. Favoriser la normalisation.La dénormalisation est une forme d'optimisation, avec tous les compromis requis, et en tant que telle, elle doit être abordée avec une YAGNI attitude.
2. Assurez-vous que le code client référençant la base de données est suffisamment découplé du schéma pour que sa refonte ne nécessite pas une refonte majeure du ou des clients.
3. N'ayez pas peur de dénormaliser lorsque cela présente un avantage évident en termes de performances ou de complexité des requêtes.
4. Utilisez des vues ou des tables en aval pour implémenter la dénormalisation plutôt que de dénormaliser le cœur du schéma, lorsque le volume de données et les scénarios d’utilisation le permettent.

Le résultat habituel de ces règles est que la conception initiale privilégiera les tableaux plutôt que les colonnes, en mettant l’accent sur l’élimination de la redondance.Au fur et à mesure que le projet progresse et que les points de dénormalisation sont identifiés, la structure globale évoluera vers un équilibre qui fait des compromis avec une redondance limitée et une prolifération de colonnes en échange d'autres avantages précieux.

Answer 2

Je plaiderais en faveur d'un plus grand nombre de tables, mais seulement jusqu'à un certain point.En utilisant votre exemple, si vous séparez les informations de votre utilisateur en deux tables, par exemple USERS et ADDRESS, cela vous donne la possibilité d'avoir plusieurs adresses par utilisateur.Une application évidente de ceci est un utilisateur qui a des adresses de facturation et de livraison distinctes.

L'argument en faveur d'une table CITY séparée serait que vous ne devez stocker qu'une seule fois le nom de chaque ville, puis vous y référer lorsque vous en avez besoin.Cela réduit effectivement le dédoublement, mais dans cet exemple, je pense que c'est exagéré.Cela peut être plus efficace en termes d'espace, mais vous en paierez le prix en jointures lorsque vous sélectionnerez des données dans votre base de données.

Answer 3

Cela ne ressemble pas tant à une question sur les tables/colonnes, mais plutôt sur la normalisation.Dans certaines situations, il y a un degré élevé de normalisation ("plus de tables" dans ce cas) est bon et propre, mais il faut généralement un nombre élevé de JOIN pour obtenir des résultats pertinents.Et avec un ensemble de données suffisamment volumineux, cela peut ralentir les performances.

Jeff a écrit un peu à ce sujet concernant la conception de StackOverflow.Voir aussi le message auquel Jeff renvoie par Dare Obasanjo.

Answer 4

Une conception entièrement normalisée (c'est-à-dire « Plus de tables ») est plus flexible, plus facile à maintenir et évite la duplication des données, ce qui signifie que l'intégrité de vos données sera beaucoup plus facile à appliquer.

Ce sont de puissantes raisons de normaliser.Je choisirais de normaliser d'abord, puis de dénormaliser seulement spécifique les tables après vous avez vu que la performance devenait un problème.

D'après mon expérience, dans le monde réel, vous n'atteindrez pas le point où la dénormalisation est nécessaire, même avec de très grands ensembles de données.

Answer 5

Cela dépend de la version de votre base de données.MS SQL Server, par exemple, a tendance à préférer les tables plus étroites.C'est aussi l'approche la plus « normalisée ».D'autres moteurs pourraient préférer l'inverse.Les mainframes ont tendance à entrer dans cette catégorie.

Answer 6

Chaque table ne doit inclure que des colonnes appartenant à l'entité identifiée de manière unique par la clé primaire.Si toutes les colonnes de la base de données sont toutes des attributs de la même entité, vous n'aurez besoin que d'une seule table avec toutes les colonnes.

Cependant, si l'une des colonnes peut être nulle, vous devrez placer chaque colonne nullable dans sa propre table avec une clé étrangère vers la table principale afin de la normaliser.Il s'agit d'un scénario courant, donc pour une conception plus propre, vous ajouterez probablement plus de tables que de colonnes aux tables existantes.De plus, en ajoutant ces attributs facultatifs à leur propre table, ils n'auraient plus besoin d'autoriser les valeurs NULL et vous éviteriez une multitude de problèmes liés à NULL.

Answer 7

La base de données multi-tables est beaucoup plus flexible si l'une de ces relations un à un peut devenir un à plusieurs ou plusieurs à plusieurs à l'avenir.Par exemple, si vous devez stocker plusieurs adresses pour certains clients, c'est beaucoup plus simple si vous disposez d'une table clients et d'une table d'adresses.Je ne vois pas vraiment de situation dans laquelle vous pourriez avoir besoin de dupliquer certaines parties d'une adresse mais pas d'autres, donc des tableaux séparés d'adresse, de ville, d'état et de code postal peuvent être un peu exagérés.

Answer 8

Comme tout le reste :ça dépend.

Il n’y a pas de règle absolue concernant le nombre de colonnes par rapport au nombre de tables.

Si vos clients doivent avoir plusieurs adresses, un tableau distinct est alors logique.Si vous avez une très bonne raison de normaliser la colonne Ville dans sa propre table, cela peut aussi fonctionner, mais je ne l'ai jamais vu auparavant car il s'agit d'un champ de forme libre (généralement).

Une conception normalisée et lourde de table est efficace en termes d'espace et semble « bonne pour un manuel », mais peut devenir extrêmement complexe.Cela a l'air sympa jusqu'à ce que vous deviez effectuer 12 jointures pour obtenir le nom et l'adresse d'un client.Ces conceptions ne sont pas automatiquement fantastique en termes de performances qui comptent le plus :requêtes.

Évitez la complexité si possible.Par exemple, si un client ne peut avoir que deux adresses (pas un nombre arbitraire), il peut alors être judicieux de les conserver toutes dans une seule table (CustomerID, Name, ShipToAddress, BillingAddress, ShipToCity, BillingCity, etc.).

Voici le message de Jeff sur le sujet.

Answer 9

Il y a des avantages à avoir des tableaux avec moins de colonnes, mais vous devez également examiner votre scénario ci-dessus et répondre à ces questions :

Le client sera-t-il autorisé à avoir plus d’une adresse ?Dans le cas contraire, une table d'adresse distincte n'est pas nécessaire.Si tel est le cas, un tableau séparé devient utile car vous pouvez facilement ajouter plus d'adresses si nécessaire ultérieurement, où il devient plus difficile d'ajouter plus de colonnes au tableau.

Answer 10

j'envisagerais de normaliser comme première étape, donc les villes, les comtés, les États et les pays seraient mieux placés dans des colonnes séparées...la puissance du langage SQL, associée aux SGBD actuels, vous permet de regrouper vos données ultérieurement si vous avez besoin de les afficher dans une autre vue non normalisée.

Lorsque le système est en cours de développement, vous pouvez envisager de « dénormaliser » certaines parties si vous considérez cela comme une amélioration.

Answer 11

Je pense qu'un équilibre est de mise dans ce cas.S'il est logique de mettre une colonne dans un tableau, mettez-la dans le tableau, si ce n'est pas le cas, ne le faites pas.L'approche de vos collègues aiderait certainement à normaliser la base de données, mais cela pourrait ne pas être très utile si vous devez joindre 50 tables ensemble pour obtenir les informations dont vous avez besoin.

Je suppose que ma réponse serait la suivante: utilisez votre meilleur jugement.

Answer 12

Il y a de nombreux aspects à cela, mais du point de vue de l'efficacité des applications, les tables mote peuvent parfois être plus efficaces.Si vous avez quelques tables avec un tas de colonnes à chaque fois que la base de données effectue une opération, elle a une chance de verrouiller, davantage de données sont rendues indisponibles pendant la durée du verrou.Si les verrous sont transmis à la page et aux tables (enfin, espérons-le, pas aux tables :)), vous pouvez voir comment cela peut ralentir le système.

Answer 13

Hmm.

Je pense que c'est un lavage et cela dépend de votre modèle de conception particulier.Éliminez définitivement les entités qui ont plus de quelques champs dans leur propre table, ou les entités dont la composition changera probablement à mesure que les exigences de votre application changent (par exemple - je prendrais en compte l'adresse de toute façon, car elle a tellement de champs, mais je 'd en particulier faites-le si vous pensez avoir besoin de gérer des adresses de pays étrangers, qui peuvent être de forme différente.Idem avec les numéros de téléphone).

Cela dit, lorsque cela fonctionne, gardez un œil sur les performances.Si vous avez créé une entité qui vous oblige à effectuer des jointures volumineuses et coûteuses, il devient peut-être une meilleure décision de conception de restaurer cette table dans l'original.

Answer 14

Il y a d'énormes avantages à requêtes en utilisant le moins de colonnes possible.Mais le tableau lui-même peut en contenir un grand nombre. Jeff dit quelque chose à ce sujet aussi.

Fondamentalement, assurez-vous de ne pas demander plus que ce dont vous avez besoin lorsque vous effectuez une requête : les performances des requêtes sont directement liées au nombre de colonnes que vous demandez.

Answer 15

Je pense que vous devez examiner le type de données que vous stockez avant de prendre cette décision.Avoir une table d'adresses est une bonne chose, mais seulement si la probabilité que plusieurs personnes partagent la même adresse est élevée.Si chaque personne avait des adresses différentes, conserver ces données dans une table différente introduit simplement des jointures inutiles.

Je ne vois pas l'avantage d'avoir une table de villes à moins que les villes en elles-mêmes ne soient des entités qui vous tiennent à cœur dans votre candidature.Ou si vous souhaitez limiter le nombre de villes disponibles pour vos utilisateurs.

En fin de compte, des décisions comme celle-ci doivent prendre en compte l’application elle-même avant de commencer à viser l’efficacité.OMI.

Answer 16

Lorsque vous concevez votre base de données, vous devez être aussi proche que possible de la signification des données et NON des besoins de votre application !

Une bonne conception de base de données devrait durer plus de 20 ans sans aucun changement.

Un client peut avoir plusieurs adresses, c'est la réalité.Si vous avez décidé que votre application est limitée à une seule adresse pour la première version, cela concerne la conception de votre application et non les données !

Il est préférable d'avoir plusieurs tables plutôt que plusieurs colonnes et d'utiliser la vue si vous souhaitez simplifier votre requête.

La plupart du temps, vous rencontrerez des problèmes de performances avec une base de données. Il s'agit de performances du réseau (requête en chaîne avec un résultat d'une ligne, récupération d'une colonne dont vous n'avez pas besoin, etc.) et non de la complexité de votre requête.

Answer 17

Tout d’abord, normalisez vos tableaux.Cela garantit que vous évitez les données redondantes, vous donnant moins de lignes de données à analyser, ce qui améliore vos requêtes.Ensuite, si vous rencontrez un point où les tables normalisées que vous rejoignez rendent le traitement de la requête trop long (clause de jointure coûteuse), dénormalisez là où cela est plus approprié.

Answer 18

Ça fait plaisir de voir autant de réponses inspirantes et bien fondées.

Ma réponse serait (malheureusement) :ça dépend.

Deux cas :* Si vous créez un modèle de données qui doit être utilisé pendant de nombreuses années et qui doit donc éventuellement subir de nombreux changements futurs :optez pour plus de tables et moins de lignes et une normalisation assez stricte.* Dans d'autres cas, vous pouvez choisir entre plus de lignes sans tableaux ou moins de lignes avec plus de tableaux.Surtout pour les personnes relativement nouvelles sur le sujet, cette dernière approche peut être plus intuitive et plus facile à comprendre.

Il en va de même pour le choix entre l'approche orientée objet et d'autres options.