实体属性值数据库与严格关系模型电子商务

Question

可以肯定地说，EAV/CR 数据库模型很糟糕。 也就是说，

问题：应该使用什么数据库模型、技术或模式来处理描述可以在运行时更改的电子商务产品的属性“类”？

在良好的电子商务中数据库中，您将存储选项类别（例如电视分辨率，然后每台电视都有一个分辨率，但下一个产品可能不是电视并且没有“电视分辨率”）。 如何存储它们、高效搜索并允许用户使用描述其产品的变量字段设置产品类型？ 如果搜索引擎发现客户通常根据控制台深度搜索电视，您可以将控制台深度添加到字段中，然后在运行时为每种电视产品类型添加单个深度。

优秀的电子商务应用程序有一个很好的共同功能，它们会显示一组产品，然后有“向下钻取”侧菜单，您可以在其中看到“电视分辨率”作为标题，以及该应用程序的前五个最常见的电视分辨率找到设置。 您单击其中一个，它只会显示该分辨率的电视，您可以通过在侧面菜单上选择其他类别来进一步深入了解。 这些选项将是在运行时添加的动态产品属性。

进一步讨论：

长话短说，互联网上是否有任何链接或模型描述可以“学术地”修复以下设置？我感谢诺埃尔·肯尼迪提出的建议类别表，但需求可能不止于此。 下面我以不同的方式描述它，试图强调其重要性。 我可能需要修正视角来解决问题，或者我可能需要更深入地研究 EAV/CR。

喜欢 EAV/CR 模型的积极反应。 我的开发人员同事都说了 Jeffrey Kemp 在下面谈到的内容：“新实体必须由专业人士建模和设计”（断章取义，请阅读下面他的回复）。 问题是：

• 实体每周添加和删除属性
  （搜索关键字决定未来属性）
• 新实体每周到达
  （产品由零件组装而成）
• 旧实体每周离开
  （已存档，不太受欢迎，季节性）

客户希望为产品添加属性有两个原因：

• 部门/关键字搜索/类似产品之间的比较图表
• 消费者结帐前的产品

配置属性必须有意义，而不仅仅是关键词搜索。 如果他们想比较所有带有“生奶油糖霜”的蛋糕，他们可以单击蛋糕，单击生日主题，单击生奶油糖霜，然后检查所有有趣的蛋糕，因为它们都有生奶油糖霜。 这不是特定于蛋糕，只是一个例子。

Answer 1

// At this point, I'd like to take a moment to speak to you about the Magento/Adobe PSD format.
// Magento/PSD is not a good ecommerce platform/format. Magento/PSD is not even a bad ecommerce platform/format. Calling it such would be an
// insult to other bad ecommerce platform/formats, such as Zencart or OsCommerce. No, Magento/PSD is an abysmal ecommerce platform/format. Having
// worked on this code for several weeks now, my hate for Magento/PSD has grown to a raging fire
// that burns with the fierce passion of a million suns.

http://code .google.com/p/xee/source/browse/trunk/XeePhotoshopLoader.m?spec=svn28&r=11#107

内部模型充其量是古怪的，就像有人将架构放入一个令人难以置信的游戏中，将其密封并将其放入油漆粉碎机中...

现实世界：我正在开发一个中间件履行应用程序，这里是获取地址信息的查询之一。

CREATE OR REPLACE VIEW sales_flat_addresses AS
SELECT sales_order_entity.parent_id AS order_id, 
       sales_order_entity.entity_id, 
       CONCAT(CONCAT(UCASE(MID(sales_order_entity_varchar.value,1,1)),MID(sales_order_entity_varchar.value,2)), "Address") as type, 
       GROUP_CONCAT( 
         CONCAT( eav_attribute.attribute_code," ::::: ", sales_order_entity_varchar.value )
         ORDER BY sales_order_entity_varchar.value DESC
         SEPARATOR '!!!!!' 
       ) as data
  FROM sales_order_entity
       INNER JOIN sales_order_entity_varchar ON sales_order_entity_varchar.entity_id = sales_order_entity.entity_id
       INNER JOIN eav_attribute ON eav_attribute.attribute_id = sales_order_entity_varchar.attribute_id
   AND sales_order_entity.entity_type_id =12
 GROUP BY sales_order_entity.entity_id
 ORDER BY eav_attribute.attribute_code = 'address_type'

懒惰地精确获取订单的地址信息

--

摘要： 仅在以下情况下使用 Magento：

1. 您正在获得大袋金钱
2. 您必须
3. 享受痛苦

Answer 2

我很惊讶没有人提到 NoSQL 数据库。

我从未在生产环境中实践过 NoSQL（刚刚测试了 MongoDB，印象深刻），但 NoSQL 的全部意义在于能够在同一个“文档”中保存具有不同属性的项目。

Answer 3

在性能不是主要要求的情况下，例如在 ETL 类型的应用程序中，EAV 具有另一个明显的优势：差异保存。

我已经实现了许多应用程序，其中首要要求是能够查看域对象从第一个“版本”到当前状态的历史记录。 如果该域对象具有大量属性，则意味着每次更改都需要将新行插入到其相应的表中（不是更新，因为历史记录会丢失，而是插入）。 假设这个域对象是一个 Person，我有 50 万个 Person 需要跟踪，在 Person 的生命周期中，各种属性平均有 100 多次更改。 再加上只有 1 个主要域对象的应用程序很少见，您很快就会推测数据库的大小将很快失去控制。

一个简单的解决方案是仅保存对主要域对象的差异更改，而不是重复保存冗余信息。

所有模型都会随着时间的推移而变化，以反映新的业务需求。 时期。 使用 EAV 只是我们工具箱中可供使用的工具之一； 但它不应该被自动归类为“坏”。

Answer 4

我正在努力解决同样的问题。 您可能会感兴趣查看以下关于两个现有电子商务解决方案的讨论：Magento (EAV) 和 Joomla（常规关系结构）：
https://forum.virtuemart.net/index.php?topic=58686.0

看起来，Magento 的 EAV 性能确实令人惊叹。

这就是为什么我倾向于标准化结构。 为了克服灵活性的缺乏，我正在考虑将来添加一些可以编辑的单独的数据字典（XML 或单独的数据库表），并基于此，用于显示和比较产品类别与新属性集的应用程序代码将是与 SQL 脚本一起生成。

在这种情况下，这种架构似乎是最佳选择——同时灵活且高性能。

该问题可能是在实际环境中频繁使用 ALTER TABLE 造成的。 我正在使用 Postgres，因此它的 MVCC 和事务性 DDL 将有望减轻痛苦。

Answer 5

如果它只是关于产品目录属性，因此这些属性的验证要求相当有限，那么 EAV 唯一真正的缺点是查询性能，甚至当您的查询处理多个具有属性的“事物”（产品）时，这只是一个问题，查询“给我 id 234 的产品的所有属性”的性能虽然不是最佳的，但仍然很快。

一种解决方案是仅将 SQL 数据库/EAV 模型用于产品目录的管理/编辑端，并采用一些流程将产品非规范化为可搜索的内容。 由于您已经拥有属性，因此您很可能需要分面，因此可以是 Solr 或 ElasticSearch。 这种方法基本上避免了 EAV 模型的所有缺点，并且增加的复杂性仅限于在更新时将完整产品序列化为 JSON。

Answer 6

我仍然投票支持 EAV 在最低意义的原子级别进行建模。 让面向特定用户群体的标准、技术和应用来决定内容模型、属性、颗粒的重复需求等。

Answer 7

EAV 有许多缺点：

1. 随着时间的推移，性能会下降
   一旦应用程序中的数据量超过一定大小，该数据的检索和操作的效率可能会变得越来越低。
2. SQL 查询非常复杂且难以编写。
3. 数据完整性问题。
   您无法为所有需要的字段定义外键。
4. 您必须定义和维护自己的元数据。

Answer 8

我有一个稍微不同的问题：我想要存储更像电子表格的东西，而不是许多具有稀疏值的属性（这可能是使用 EAV 的一个很好的理由）。 工作表中的列可以更改，但工作表中的所有单元格都将包含数据（不是稀疏的）。

我做了一个一小组测试来对两种设计进行基准测试：一个使用 EAV，另一个使用用于存储单元格数据的 Postgres ARRAY。

EAV

数组

两种模式都在适当的列上有索引，并且索引由规划器使用。

事实证明，基于数组的模式速度快了一个数量级 用于插入和查询。 从快速测试来看，两者似乎都是线性扩展的。 不过，测试还不是很彻底。 欢迎提出建议和叉子 - 它们获得了麻省理工学院的许可。

Answer 9

我能想到一些一般的优点和缺点，在某些情况下，一种比另一种更好：

选项 1，EAV 模型：

• 优点：设计和开发简单应用程序的时间更少 优点
• ：新易于添加的实体（甚至可能
  由用户添加？）
• 优点：“通用”接口组件
• 缺点：验证简单数据类型需要复杂的代码
• 缺点：简单的 SQL 需要复杂得多
  报告
• 缺点：复杂的报告可能会变得几乎
  不可能
• 缺点：大型数据集的性能较差

选项 2，分别对每个实体建模：

• 缺点：收集数据需要更多时间
  需求和设计
• 缺点：必须对新实体进行建模并
  由专业人士设计
• 缺点：为每个组件定制界面组件
  实体
• 优点：数据类型约束和验证易于实现
• 优点：SQL 易于编写、易于实现
  理解和调试
• Pro：即使是最复杂的报告也相对简单
• Pro：大型数据集的最佳性能

选项 3，组合（“正确”模型实体，但为某些/所有实体的自定义属性添加“扩展”）< /strong>

• 优点/缺点：收集需求和设计所需的时间比选项 1 更多，但可能没有选项 2 那么多 *
• ：新实体必须由专业人士建模和设计 优点
• ：稍后可以轻松添加新属性 缺点
• 缺点 ：验证简单数据类型需要复杂的代码（对于自定义属性）
• 缺点：仍然需要自定义接口组件，但自定义属性可能可以使用通用接口组件
• 缺点：一旦报表中包含任何自定义属性，SQL 就会变得复杂
• 缺点：通常性能良好，除非您开始需要按自定义属性进行搜索或报告

* 我不确定选项 3 是否一定会在设计阶段节省任何时间。

我个人倾向于选项 2，并尽可能避免 EAV。 然而，对于某些场景，用户需要 EAV 带来的灵活性； 但这需要付出巨大的代价。

Answer 10

可以肯定地说，EAV/CR 数据库模型很糟糕。

不，这不对。 只是它们是关系数据库的低效使用。 纯粹的键/值存储非常适合此模型。

现在，回答您真正的问题：如何存储各种属性并使它们可搜索？

只需使用 EAV 即可。 在你的情况下，这将是一个额外的表。 在属性名称和值上对其进行索引，大多数 RDBM 会使用前缀压缩来对属性名称重复进行压缩，从而使其变得非常快速和紧凑。

当您使用 EAV/CR 替换“真实”字段时，它会变得丑陋。 与所有工具一样，过度使用它是“不好的”，并且会给它带来不好的形象。