Compact vs Loose Database

J'ai deux tables A et B.Compact vs Loose Database

Quelle est la conception préférée?

(tout en un)

Tableau A: Numéro d'article || Catégorie || Sous-catégorie

ou (séparé)

Tableau A: Catégorie || Sous-Catégorie

Tableau B: Numéro d'article || Sous - catégorie

Interrogation ALLINONE:

Select article_id from tableA where article id = foo and 
    Category = bar and sub category = baz;

Interrogation départage:

Select article_id from tableB inner join tableA 
    where tableA.sub-category = tableB.sub-category and tableA.category = Category;

TOUT-EN directe au point mais SEPARE est beaucoup plus propre.

Qu'est-ce qui est le plus rapide et le plus recommandé?

Source

2013-07-02 o2kevin

Je n'ai aucune idée de ce que vous demandez. –

données réelles, structure de la table réelle, de vraies questions - s'il vous plaît. il semble que vous parliez de ** [normalisation de la base de données] (https://en.wikipedia.org/wiki/Database_normalization) ** –

Déjà édité. – o2kevin

La première version est de stocker toutes les informations de hiérarchie dans un seul enregistrement

La deuxième version pointe vers le niveau le plus bas de la hiérarchie et en se référant ensuite à travers celle au niveau supérieur (s).

En général, une approche plus normalisée (la deuxième approche) est la façon la plus «naturelle» d'exprimer une telle relation. Par exemple, ce que vous appelez une "sous-catégorie" pourrait être un "produit" et la "catégorie" pourrait être un attribut d'un "produit". Il est logique de stocker le produit dans un tableau séparé.

Il y a (au moins) une situation où vous ne voulez pas faire cela. Parfois, les relations entre la catégorie et la sous-catégorie changent avec le temps et vous souhaitez maintenir la relation à un moment donné. C'est ce qu'on appelle une qui change lentement de cote. Dans ce cas, vous souhaitez capturer toutes les informations sur la sous-catégorie et la catégorie dans un seul enregistrement.En d'autres termes, il est impossible de dire quel est de préférence globalement. Typiquement, la deuxième méthode (plus normalisée) résout plus de problèmes d'affaires. Il y a des circonstances où le premier pourrait être plus attrayant.

Source

2013-07-02 01:42:02

veuillez faire pas optimiser prématurément. Commencez avec des tables normalisées ou fournissez plus d'informations réelles!

Source

2013-07-02 01:16:14 DRC

argh, quelle honte je ne peux pas poster de commentaires. – DRC

... a déclaré @drc dans un commentaire. De toute façon, vouliez-vous dire "S'il vous plaît ne pas optimiser prématurément?" – icedwater

@icedwater vous avez bien raison, modifié. – DRC

Pour la requête exemple, vous montrer, il serait probablement plus rapide si vous utilisez une seule table, et de définir un indice à plusieurs colonnes au cours des trois colonnes (article_id, category, subcategory). Mais gardez à l'esprit que vous voudrez peut-être exécuter une autre requête plus tard sur la même table (s), et il bénéficierait d'une organisation et des index différents. Nous décidons des optimisations de performance basées sur les requêtes, pas les tables. Il est donc utile de faire une analyse de toutes les façons d'interroger les données. PS: Il n'y a pas d'opérateur == dans SQL.

Source

2013-07-02 01:27:59

OH yeah. désolé j'ai mélangé les codes PHP et SQL. Je vais l'éditer – o2kevin

Si votre catégorisation est si simple et si basique. Si chaque article peut être trouvé dans une seule catégorie et qu'il n'y a pas de structure hiérarchique pour vos catégories, vous pouvez utiliser la première conception de la table. Sinon, vous devez utiliser un autre design.

Source

2013-07-02 02:54:23 SaidbakR

Compact vs Loose Database

Répondre

Questions connexes