（数据库设计，mysql）我的数据库设计适合基本购物车吗

我在数据库设计方面是个新手，我想确保我做得很好。 请查看我的部分数据库设计：

我的基本购物车数据库设计：

//table that holds shopping cart items that customer choose(not press checkout and order //them)

**shopping_cart**
{
id (int)
product_id (int) fk
product_quantity (int)
customer_user_id (int) fk 
}

//table that holds product order data in time of checkout.(i hold them because supplier //can change after time products attributes value add some attributes or delete and change //the price of product)

**order**
{
id (int)
product_id (int)  fk
customer_user_id (int)  fk
}


//table that connect order  to attribute table for products attributes value in the moment //of   checkout

**order_attributes**
{
id (int)
order_id (int)  fk
attribute_id (int)  fk
}

//main product table
**product**
{
id (int)
sku (int) 
product_name (varchar)
supplier_user_id (int)  fk
}

//connection table many to many 
**product_attributes**
{
id (int) 
product_id (int)  fk
attribute_id (int)  fk
}

//table that holds products attributes (price, weight, color + new attributes that user //will create)

**attribute**
{
id (int)
product_id (int)  fk
attribute_name (varchar)
attribute_value(varchar)
}

---

谢谢你给我钱，这是一个糟糕的设计，因为它使用属性表而不是EAV表，这可能会导致性能问题。花点时间为产品实际定义您想要的属性，对于大多数产品（颜色、大小、单位（10件装、单品等））来说，实际上都有很多相似之处。EAV是最后的选择

在orderdetail表中存储价格等的详细信息。如果以后产品价格发生变化，您不希望价格发生变化

我的结构会像这样： 命令 订单ID、日期、客户ID 订单详情 订单id、公司id、产品id、零件号、产品名称、数量、价格、单位、颜色、大小、其他属性 订单 订单号，备注

产品 产品标识、零件号、产品名称、公司标识、产品价格、颜色、尺寸、单位

当某些产品没有相同的属性时，最好使用空列（除非您有数百个通常不会使用的属性）

---

此外，如果你想要一个完整的产品规格，考虑把它们放在一个大的VARCHAR存档，并把全文索引放在上面。这应该比EAV表的性能更好。

Hmm有两个表可以从设计中删除：订单属性、产品属性。否则，您的select查询将非常慢，必须从如此多的表中进行连接。您可以将属性作为列存储在订单和产品表中。

为什么magento使用EAV表？另外，在我的应用程序中，我不知道产品的属性，因为供应商定义了它们。如果每个供应商都能添加新属性，那么表产品将有很多列。EAV表是性能杀手，很难编写代码。如果您不知道一个零件有多少属性，您甚至不知道要加入表多少次。由于每个查询都会多次连接到这个表，因此会产生锁定问题，通常意味着一旦有了真正的工作负载，性能将非常糟糕。我也不会让供应商添加列。选择零件需要六个左右的属性（颜色、尺寸、重量、单位等）。其他的都是描述性的，应该存储在一个带有全文索引的大字段中。我使用过的应用程序有来自数千家供应商的部件，这些部件在描述上具有很高的技术性，我们从来都不需要更多的部件。人们过分强调灵活性，数据库的灵活性会带来巨大的性能成本，如果您进行尽职调查并找出真正需要的是什么，则在大多数情况下都是不必要的。我们有一个COTS产品，我们为此支付了10万多美元，它的设计方式非常缓慢，而且不可靠；我们没有它应该拥有的所有东西，所以我们已经花费了无数的人力来添加应该存在的字段。它已经变得如此糟糕，我们正准备放弃它的东西，没有广泛的定制工作。非常感谢。你对spree（电子商务-reils上的rubi）数据库设计有何看法？参见模型图如果你喜欢我的答案，你也可以将其设置为正确的答案lol