2012-04-04 51 views
3

我即将登上我的第一个电子商务数据库。电子商务项目的数据库设计(我应该使用EAV方法)

我在大多数电子商务网站上发现的是,这些网站有类别,然后是子类别,然后再次子类别等。并且子类别的深度不固定表示一个类别具有六个嵌套子类别,而其他类别具有不同

现在所有产品都具有与其关联的属性。

现在我的问题是,是这些网站不断添加表嵌套子类别,并保持在数据库中添加列的属性

OR

它们适用的东西被称为“EAV”模式(如果我是对的)来解决这个问题,或者他们不断添加列和/或表格,并且不断更新网页,就像我在许多网站上发现的那样,现在有一个新的类别。

(如果他们使用EAV模型,则网站性能影响不是它..)

因为这是我的第一个电子商务项目,请您提供一些有价值的建议。

感谢,

任何帮助表示赞赏。

+0

阅读[这篇优秀的文章(“坏CaRMa”)](http://www.simple-talk.com/opinion/opinion-pieces/bad-carma/),并参见[在这5个最高的错误列表在数据库设计中(点#3)](http://www.simple-talk.com/sql/database-administration/five-simple--database-design-errors-you-should-avoid/)为什么EAV是一个可怕的坏主意..... – 2012-04-04 12:32:58

回答

6

你需要的是一个组合EAV的对产品功能嵌套集产品类别

尽管我当然同意EAV几乎总是一个不错的选择,但其中EAV是完美选择的一个应用程序是用于处理在线目录中的产品属性。

想想网站如何显示产品属性...产品的属性始终显示为一个垂直列表,其中包含两列:“属性”|“ “值”。有时候这些列表会显示多个产品的并行比较。 EAV完美适合做这种事情。对于大多数应用而言,使EAV毫无意义且效率低下的东西正是使EAV对于在线目录中的产品属性有意义且高效的原因。

大家总是说“EAV是EVIL!”的原因之一是因为列名(即属性的含义)是由表驱动的,因此EAV中的属性是“无意义的”,因此不被模式定义。模式的全部重点是给你的模型意义,所以这一点很好。 但是在一个在线产品目录的情况下,产品属性的含义真的不重要给系统本身。您的产品目录系统关心产品属性的唯一原因是将它们转储到列表中或可能存储在产品比较矩阵中。因此在这种特殊情况下,EAV并不是邪恶的

对于产品类别,您需要一个嵌套集模型,如我在this question的答案中所述。嵌套集使您能够快速检索,并且能够遍历多层次的不平衡层次结构,但会牺牲编辑时的一些预先计算工作量。

相关问题