我有一个现有的成熟模式，我们需要向其中添加一些新的产品属性。例如，我们有 Products.Flavor，现在需要添加新的属性，如重量、香味等。与其继续扩大 Products 表，我正在考虑其他几个选项。首先是一个新的 Attributes 表，它将有效地成为任意属性的属性包，以及一个 ProductsAttributes 表，用于存储特定产品属性的映射（和值）。这是实体-属性-值 (EAV) 模式，正如我所理解的那样。另一个选项是向 Products 表中添加一个名为 Attributes 的新列，该列是 XML 类型的。在这里，我们可以在不添加新表的情况下，任意给任何产品实例添加属性。
每种方法的优点/缺点是什么？我正在使用 SQL Server 2008 和 ASP.NET 4.0。
这是（恕我直言）经典的数据库设计问题之一。称它为“属性蠕变”，也许，一旦你开始，总会有另一个属性或属性要添加。他们的关键决定是，您是使用数据库提供的基本工具（表和列）将数据存储在数据库中，以构造和格式化数据，还是以其他方式（XML 和名称/值对）存储数据是最常见的替代品）。简而言之，如果您以 DBMS 系统不支持的形式存储数据，那么您将失去 DBMS 系统管理、维护和使用该数据的能力。如果您只需要将其存储为“blob 数据”（将其全部转入，全部抽出），这不是什么大问题，但是一旦您开始必须按此数据查找、排序或过滤，它可以得到非常丑非常快。
话虽如此，我确实对名称/值对和 XML 有强烈的看法，但遗憾的是，没有一个是积极的。如果您确实必须以这种方式存储数据，并且是的，这可能是一个完全有效的业务/设计决策，那么我建议您仔细研究您需要存储在数据库中的数据将如何在未来。根据使用方式权衡每种方法的优缺点，然后选择最容易管理和维护的方法。（不要选择最容易实现的那个，你支持它的时间会比你写它的时间长得多。）
（它很长，但“RLH”文章是名称/值对横行的经典示例。）
（哦，如果您正在使用它，请查看 SQL Server 2008 的“稀疏列”选项。听起来不像您需要的，但您永远不知道。）