30

我正在为电子商务应用程序设计我的数据库/域，我很难弄清楚如何存储产品。

该网站将出售各种各样的产品，钢笔、丁字裤、纹身、雨伞，应有尽有。这些产品中的每一个都有一些共同的属性，高度、宽度、长度、重量等，但有些产品有特殊的数据。例如，钢笔有不同的墨水颜色，笔尖/盖子和小册子可以有不同类型的折叠。到目前为止，我已经想到了大约 20 多个额外属性，但这些属性可能只适用于网站上 1% 的产品。

所以我想知道是否适合实施 EAV 模型来处理额外的数据。请记住，当客户在前端查看网站时，将会有一个过滤侧边栏，就像在 eBay 和 carsales.com.au 上一样。（所以请记住，会有相当多的查询）

我认为实现类表继承并不实际，因为系统需要保持灵活性。这是因为，在未来，我们可能会在新类型的产品中拥有更多的属性。

我考虑的另一件事是使用 NoSQL 数据库（可能是 MongoDB）但是我对这些类型的数据库几乎没有经验，它甚至可以解决我的问题吗？

审查选项：

  1. 具有大量列的单个产品实体
  2. 分离属性实体 (EAV)
  3. 切换到无模式持久性

我正在使用属性实体构建原型以查看它的灵活性，并测试性能以及查询如何失控。

编辑：当然，我对任何其他解决方案持开放态度。

4

3 回答 3

69

很好的问题，但当然，没有“一种真正的方法”。根据@BenV，Magento 确实使用 EAV 模型。我对它的体验非常积极，但它确实让其他用户感到不安。一些考虑：

1. 性能。 EAV 需要复杂的多表连接来使用相关属性填充您的对象。这确实会影响性能。但是，可以通过仔细缓存（通过堆栈的所有级别，包括查询缓存）和选择性使用非规范化来缓解这种情况。Magento 确实允许管理员为 SKU 数量（通常为数千个）保证的类别和产品选择非规范化模型。这反过来需要观察者触发重新索引（总是好的！）并在产品数据更改时更新“平面”非规范化表。这也可以安排或手动触发，并提示管理员。

2. 3rd Party User Complexity 如果你打算让这个应用程序对其他用户可用，很多人会发现 EAV 太复杂了，你最终会在用户论坛上处理大量的咩咩声和不知情的滥用（参考 Magento ！！） .

3. 未来的可扩展性和插件架构。 毫无疑问，当可扩展性成为一个因素时，EAV 模型真正发挥作用。将新属性添加到模型中非常简单，同时将破坏现有 ORM 和控制器代码的风险降至最低。

4. 数据类型的更改 EAV 确实使更改属性数据类型变得更加困难。int如果您的初始设计需要将来更改的特定属性数据类型（例如varchar），则意味着您必须将该属性的所有记录迁移到与新数据类型匹配的相应表中。当然，纯粹主义者会建议你在第一时间就做好设计，但现实有时会闯入！

5. 手动产品导入 EAV 使几乎不可能的一件事是使用 SQL 和/或 phpMyAdmin 样式的 CSV/XML 将产品（或其他实体）导入数据库。您需要编写一个 Importer 模块来接受结构化数据并将其传递到应用程序的模型层以将其持久保存到数据库中。这确实增加了您的复杂性。

于 2010-11-01T04:05:50.280 回答
0

开源购物车Magento允许使用 EAV 设计为其产品自定义属性。您可以在此处查看他们的数据库架构。

于 2010-11-01T03:52:41.653 回答
0

我建议您仔细研究带有 OXM 插件的 Doctrine 2 ORM (https://github.com/doctrine/oxm)。它将以不同的属性解决您的问题。当然，您将需要为可搜索的自定义属性建立索引，但我认为这不是问题 :)

如果您不关心社区成员的数量，那么您也可以使用 MongoDB。

于 2011-03-11T10:48:44.837 回答