(Database Design - products attributes): What is better option for product attribute database design?

问题

I new in database design. What is better option for product attribute database design for cms?(Please suggest other options also).

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
}

回答1:

You're making a common mistake of database design, storing name in one column and value in another column. This is not a relational database design.

Each attribute should be named by the column name. Color, pages, shirt size, publish date, should be column names.

If each product type has a distinct set of attributes, there are other solutions. See my answers to:

Product table, many kinds of product, each product has many parameters for details.
How do you model custom attributes of entities?
Design question: Filterable attributes, SQL
How to design a database schema to support tagging with categories?
How to define structure in a tag-based organization?

Also please read this story: Bad CaRMa: Introducing Vision before you implement a database designed around name-value pairs as you are doing.

回答2:

i think that the best implementation for product attribute you can get is

Product_Tbl [
    ID
    Name
    more columns
]

Attribute_Tbl [
   ID
   Att_Name
]

Product_Attribute_Tbl [
    Product_ID
    Attribute_ID
    Value
]

if your products not have the same attributes you can use this structure

回答3:

That depends on what do you want from your database. If all of your products are of the same type and have same attributes then you just need to do something like that:

products{id: integer, product_name: string, color: string, attribute_name1: string, attribute_name2: string...}. Attribute_name{} should a meaningful word, just like "color" (which is an attribute too).

回答4:

This is now an old topic, but thought it might be interesting to think about how this has evolved (especially with more processing speed means performance can be gambled at times).

Have you ever considered storing each attribute as a separate item in table ... lets say table "2", where the key back to the product would be an id:

    Product (table 1)
{
    Product ID
    Product Name
}

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

And that this table would contain also a field called "higher level" so you could find the unique ID within this table of which attribute was created as a higher level for this specific product. That way you have something called "omnilevel tagging".

Hope this helps

来源：https://stackoverflow.com/questions/2945045/database-design-products-attributes-what-is-better-option-for-product-attri

标签

relational-database

entity-attribute-value

database-design