9

Je suis nouveau dans la conception de base de données. Quelle est la meilleure option pour la conception d'une base de données d'attributs de produit pour cms? (Veuillez également suggérer d'autres options).(Conception de base de données - attributs de produits): Quelle est meilleure option pour la conception de base de données d'attribut de produit?

option 1: 1 table

products{ 
id 
product_name 
color 
price 
attribute_name1 
attribute_value1 
attribute_name2 
attribute_value2 
attribute_name3 
attribute_value3 
} 

option 2: 3 tables

products{ 
id 
product_name 
color 
price 
} 

attribute{ 
id 
name 
value 
} 

products_attribute{ 
products_id 
attribute_id 
} 

Merci, Yossef

+0

À quelle fréquence les attributs changent-ils? Avez-vous souvent ajouter/supprimer de nouveaux? Si ce n'est pas le cas, utilisez l'option 1 avec les noms des colonnes étant le nom de l'attribut. Si vos attributs sont dynamiques, utilisez l'option 2. Bien sûr, pour l'option 2, vous obtiendrez une baisse de performance. –

+0

Toujours selon Bill, regardez vos réponses précédentes et soyez un bon citoyen et acceptez ceux qui ont fonctionné pour vous. (Juste un clic de souris) –

+0

J'ajoute le vote, merci de m'avoir dit.Notre application web est dinamique- cela signifie que chaque utilisateur définit ses attributs.Le problème avec l'option 2 que ce sera très lent et avec l'option 1 nous pouvons donner max comme 10 attributs pour le produit que nous ne connaissons pas le nom et sa valeur définissent à l'utilisateur. – Yosef

Répondre

22

Vous faites une erreur courante de conception de base de données, en stockant le nom dans une colonne et la valeur dans une autre colonne. Ce n'est pas une conception de base de données relationnelle.

Chaque attribut doit être nommé par le nom de la colonne. Couleur, pages, taille de chemise, date de publication, devrait être noms de colonnes.

Si chaque type de produit possède un ensemble distinct d'attributs, il existe d'autres solutions. Voir mes réponses à:

également s'il vous plaît lire cette histoire: Bad CaRMa: Introducing Vision avant d'implémenter une base de données conçue autour des paires nom-valeur que vous faites.

+0

merci Bill, je donne aussi mes votes à d'autres mes questions, merci de me le dire. – Yosef

+0

Salut Bill, je lis Vous liens Merci, J'ai une question: Pourquoi préférez-vous utiliser ** Class Table Héritage ** et non ** ** Single Table Héritage **? Veuillez expliquer, Merci, Yosef – Yosef

+0

@Yosef: Avec l'héritage de table de classes, il est plus clair quels groupes de colonnes vont ensemble. Vous pouvez également ajouter une nouvelle table de sous-types à tout moment, avec son propre ensemble de colonnes spécifiques au type, sans avoir besoin de modifier la table parent qui contient des colonnes communes à tous les sous-types. Ceci est important par exemple pour MySQL, où 'ALTER TABLE' est une opération coûteuse. –

1

Cela dépend de ce que vous voulez de votre base de données. Si tous vos produits sont du même type et ont les mêmes attributs, vous devez simplement faire quelque chose comme ça:

products {id: entier, nom_produit: chaîne, couleur: chaîne, nom_attribut1: chaîne, nom_attribut2: chaîne. ..}. Attribute_name {} devrait être un mot significatif, tout comme "color" (qui est aussi un attribut).

+0

Non, ils ne sont pas les mêmes parce que j'ajoute 2 champs: 1. nom 2. valeur – Yosef

3

je pense que la meilleure mise en œuvre pour le produit d'attributs que vous pouvez obtenir est

Product_Tbl [ 
    ID 
    Name 
    more columns 
] 

Attribute_Tbl [ 
    ID 
    Att_Name 
] 

Product_Attribute_Tbl [ 
    Product_ID 
    Attribute_ID 
    Value 
] 

si vos produits n'ont les mêmes attributs que vous pouvez utiliser cette structure

0

Ceci est maintenant un vieux sujet, mais la pensée il pourrait être intéressant de réfléchir à la manière dont cela a évolué (en particulier avec plus de vitesse de traitement, les performances peuvent parfois être jouées).

Avez-vous déjà envisagé de stocker chaque attribut comme un élément distinct dans le tableau ...permet de dire la table « 2 », où la clé sur le produit serait un id:

Product (table 1) 
{ 
    Product ID 
    Product Name 
} 

    Tags (table 2) 
{ 
    Tag ID 
    Higher Level tag ID 
    Description 
    Value 
    Product ID 
} 

Et que ce tableau contiendrait également un champ appelé « niveau supérieur » pour que vous puissiez trouver l'ID unique dans ce tableau dont l'attribut a été créé en tant que niveau supérieur pour ce produit spécifique. De cette façon, vous avez quelque chose appelé "omnilevel tagging".

Espérons que cela aide

Questions connexes