实体属性值（EAV）与XML列的新产品属性比较

Question

我有一个现成的、成熟的模式，我们需要添加一些新的产品属性。例如，我们有Product.Flavor，现在需要添加新属性，如Weight、Fragrance等。与其继续扩大产品表，我正在考虑其他几个选项。第一个是一个新的Attributes表，它将有效地成为任意属性的属性包，以及一个ProductsAttributes表来存储特定产品属性的映射(和值)。这是我所理解的实体-属性-值(EAV)模式。另一个选项是向Products表添加一个名为Attributes的新列，它的类型是XML。在这里，我们可以任意地向任何产品实例添加属性，而不必添加新表。

各种方法的优缺点是什么？我使用的是SQL Server 2008和ASP.NET 4.0。

- Mark Richman

---

（我现在收藏这个问题，以便稍后回来并点赞所有“你真的不想这样做”的答案） - Philip Kelley

我真的不想做哪一个选项？;-) - Mark Richman

向产品表中添加新列有什么问题吗？这些属性只与某些产品子集相关吗？ - tster

问题（如果你想这么称呼它）是新属性的数量几乎肯定会随着时间的推移而增加，我希望避免一年后出现100列的表格。 - Mark Richman

将产品分成类别，并为每个产品类别单独创建一个表，这样做有助于保持每个表的列数合理吗？我认为这是一种主从关系的方法。 - Andriy M

Answer 1

在我看来，这是经典的数据库设计问题之一。也许可以称之为“属性蔓延”，因为一旦开始，就会有另一个属性或属性要添加。关键决策是，您是否使用数据库提供的基本工具（表和列）来结构化和格式化数据在数据库中存储数据，还是以其他方式存储数据（XML和名称/值对是最常见的替代方案）。简而言之，如果您以不受DBMS系统支持的形式存储数据，则失去了DBMS系统管理，维护和处理该数据的能力。如果您只需要将其存储为“blob数据”（全部倒入，全部排出），则这不是什么大问题，但是一旦您开始寻找，排序或按此数据过滤，它可能会变得非常丑陋，非常快。

说实话，我对于名称/值对和XML有很强的意见，但遗憾的是，没有一个是积极的。如果你确实需要以这种方式存储数据，并且是完全有效的业务/设计决策，那么我建议你仔细考虑将来需要存储在数据库中的数据将如何被使用和访问。权衡每种方法的优缺点，并选择最容易管理和维护的方法。(不要选择最容易实现的方法，因为你将支持它的时间比编写它的时间长得多。)

(虽然有些冗长，但“RLH”论文是名称/值对失控的经典例子。)

(哦，如果你正在使用它，请了解SQL Server 2008的“稀疏列”选项。听起来似乎不是你需要的，但你永远不知道。)

- Philip Kelley

---

感谢您的反馈。我们刚刚就这个问题进行了一次小会议，并决定使用表格而不是 XML，原因正如您所述。现在只需要负责任地使用 EAV 模式即可。 - Mark Richman