电子商务项目的数据库设计（我应该使用EAV方法） [英] Database Design for ECommerce project (Should I use EAV Approach)

问题描述

我即将设计我的第一个电子商务数据库。

我在大多数电子商务网站中发现，这些网站有类别，然后是子类别再次SubCategory等等。而SubCategory的深度不是固定的，一个类别有六个嵌套子类别，另一个类别有不同的

现在所有的产品都有与之相关的属性。

现在我的问题是这些网站是否继续添加嵌套子类别的表，并继续添加数据库中属性的列

OR

他们应用称为EAV模型的东西（如果我是对的）来解决这个问题，或者继续添加列（或）表格，并且继续更新WebPages，就像许多网站，我发现现在有一个新的类别。

（如果他们使用EAV模型，那么网站的性能是因为这是我第一个ECommerce项目，请提供一些有价值的建议。

>谢谢，

任何帮助都不胜感激。

解决方案

p>虽然我肯定同意EAV几乎总是一个坏的选择，一个EAV是完美的选择的应用程序是在线目录中处理产品属性。<​​/ p>

想想网站如何显示产品属性...产品的属性始终显示为具有两列的垂直列表：属性| 值。有时这些列表显示了多个产品的并排比较。 EAV非常适合做这样的事情。对于大多数应用程序，使EAV无意义和低效的东西正是使EAV对在线目录中的产品属性有意义和有效的。

大家总是说EAV是EVIL！因为列名（即属性的含义）是表驱动的，因此EAV中的属性是无意义的，因此不被模式定义。模式的整体是给出你的模型意义，所以这一点是很好的。 在线产品目录的情况下，产品属性的含义对于本身来说真的不重要。目录系统关心产品属性的唯一原因是将它们转储到列表或可能的产品比较矩阵中。因此，在这种特殊情况下，EAV不会发生恶毒。

对于产品类别，您需要一个嵌套集合模型，正如我在这个问题。嵌套集可以非常快速的检索，同时可以以编辑时间的一些预计算作为代价，跨越多层次的不平衡层次结构。

I am about to deign my first E-Commerce Database.

What i have find out in most E-Commerce websites is that these sites have Category, then SubCategory and then again SubCategory and so on. And the depth of SubCategory is not fixed means One Category have six nested Sub Category while some other have different

Now All the products have attributes associated with it.

Now my question is are these websites keep on adding tables for nested sub categories and keep on adding columns for the attributes in the database

OR

They apply something called as "EAV" model (if i am right) to solve this problem or they keep on adding columns and or tables and also keep on updated the WebPages as on many sites i have found there is now a new category.

(If they use EAV model then the website performance is impacted isnt it..)

Since this is my first ECommerce project please provide some valuable suggestions of yours.

Thanks,

Any help is appreciated.

解决方案

What you need is a combination of EAV for product features and nested sets for product categories.

While I certainly agree that EAV is almost always a bad choice, one application where EAV is the perfect choice is for handling product attributes in an online catalog.

Think about how websites show product attributes... The attributes of products are always shown as a vertical list with two columns: "Attribute" | "Value". Sometimes these lists show side-by-side comparisons of multiple products. EAV works perfectly for doing this kind of thing. The things that make EAV meaningless and inefficient for most applications are exactly what makes EAV meaningful and efficient for product attributes in an online catalog.

One of the reasons why everyone always says "EAV is EVIL!" is that the attributes in EAV are "meaningless" insofar as the column name (i.e. meaning of the attribute) is table-driven and is therefore not defined by the schema. The whole point of schemas is to give your model meaning so this point is well taken. However in the case of an online product catalog, the meaning of product attributes is really unimportant to the system, itself. The only reason your catalog system cares about product attributes is to dump them in a list or possibly in a product comparison matrix. Therefore EAV is doesn't happen to be evil in this particular case.

For product categories, you want a nested set model, as I described in the answer to this question. Nested sets give you very quick retrieval along with the ability to traverse multiple levels of an unbalanced hierarchy at the expense of some precalculation effort at edit time.

这篇关于电子商务项目的数据库设计（我应该使用EAV方法）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！