Quelle est la meilleure conception de base de données: plus de tables ou de colonnes?

Question

Un ancien collègue de travail a insisté pour qu'une base de données avec plusieurs tables avec moins de colonnes qu'il est mieux que celui avec moins de tables avec plus de colonnes. Par exemple, plutôt que d'une table client avec nom, adresse, ville, état, code postal, etc. colonnes, vous devez avoir un nom de table, une table d'adresse, une ville, une table, etc.

Il a soutenu cette conception a été plus efficace et plus souple. C'est peut-être plus souple, mais je ne suis pas qualifié pour juger de leur efficacité. Même si c'est plus efficace, je pense que ces gains peuvent être compensés par la complexité ajoutée.

Donc, y at-il des avantages significatifs à plusieurs tables avec moins de colonnes sur moins de tables avec plusieurs colonnes?

Answer 1

J'ai quelques règles assez simples de pouce que j'ai suivi lors de la conception de bases de données, ce qui je pense peut être utilisé pour aider à prendre des décisions de ce genre....

1. Faveur de la normalisation. La dénormalisation est une forme d'optimisation, avec tous les nécessaires compromis, et comme telle, elle doit être abordée avec une YAGNI attitude.
2. Assurez-vous que le code client de référencement de la base de données est découplé du schéma de retravailler il ne nécessite pas d'une refonte majeure du client(s).
3. N'ayez pas peur de dénormaliser quand elle offre des avantages évidents pour la performance ou à la requête de la complexité.
4. Utiliser les vues ou en aval des tableaux pour mettre en œuvre la dénormalisation plutôt que la dénormalisation de la base du schéma, lorsque le volume de données et de scénarios d'utilisation le permettent.

Le résultat habituel de ces règles est que la conception initiale de favoriser les tables de plus de colonnes, avec un accent sur l'élimination de la redondance. À mesure que le projet progresse et la dénormalisation points sont identifiés, l'ensemble de la structure va évoluer vers un équilibre de compromis avec peu de redondance et de la colonne prolifération en échange d'autres avantages de valeur.

Answer 2

C'est comme les querelles, un tracteur est mieux qu'un chercheur d'or.

Il n'est pas vraiment sur les tables, c'est sur les fins qu'ils servent.

Answer 3

Je voudrais plaider en faveur de plus de tables, mais seulement jusqu'à un certain point. À l'aide de votre exemple, si vous vous êtes séparé de votre informations de l'utilisateur dans les deux tables, disent les UTILISATEURS et l'ADRESSE, cela vous donne la possibilité d'avoir plusieurs adresses par l'utilisateur. Une application évidente de ce qui est un utilisateur qui a séparé de facturation et adresse de livraison.

L'argument en faveur d'avoir séparé la VILLE de tableau serait que vous ayez besoin de stocker chaque nom de la ville, puis de les consulter quand vous en avez besoin. Qui ne de réduire la duplication, mais dans cet exemple, je pense que c'est exagéré. Il peut être plus efficace de l'espace, mais vous aurez à payer le prix dans les jointures lorsque vous sélectionnez des données à partir de votre base de données.

Answer 4

Le son n'est pas tellement comme une question à propos de tables/colonnes, mais à propos de la normalisation. Dans certaines situations, avoir un degré élevé de normalisation ("plus de tables" dans ce cas) est bon, et propre, mais il faut généralement un grand nombre de Jointures pour obtenir des résultats pertinents. Et avec un assez grand jeu de données, ce qui peut ralentir les performances.

Jeff a écrit un peu sur le sujet concernant la conception de StackOverflow. Voir aussi le post de Jeff liens par Dare Obasanjo.

Answer 5

Cela dépend de votre base de données de la saveur. MS SQL Server, par exemple, a tendance à préférer le plus étroit des tables. C'est aussi le plus "normalisés" approche. D'autres moteurs de préférer l'autre sens. Les Mainframes ont tendance à tomber dans cette catégorie.