我有一个现有的成熟模式，我们需要添加一些新的产品属性。例如，我们有Products.Flavor，现在需要添加新的属性，例如Weight，Fragrance等。我不考虑继续扩大Products表格，而是考虑其他一些选项。首先是一个新的属性表，它将有效地作为任意属性的属性包，以及一个ProductsAttributes表，用于存储特定产品属性的映射（和值）。这是实体 - 属性 - 值（EAV）模式，我已经了解它。另一种选择是向名为Attributes的Products表添加一个新的列，该表是XML类型。在这里，我们可以任意添加属性到任何产品实例而无需添加新表格。实体属性值（EAV）与XML列对于新产品属性
每种方法的优缺点是什么？我正在使用SQL Server 2008和ASP.NET 4.0。
这是（imho）经典数据库设计问题之一。也许，称它为“属性蔓延”，因为一旦你开始，总会有另一个属性或属性添加。他们的关键决定是，是否使用数据库提供的基本工具（表和列）将数据存储在数据库中以构建和格式化数据，还是以其他方式（XML和名称/值对）存储数据是最常见的替代品）。简而言之，如果您以非DBMS系统支持的形式存储数据，那么您将失去DBMS系统管理，维护和处理数据的能力。如果您只需要将其存储为“blob数据”（将其全部转储，全部抽出），那么这不是什么大问题，但是一旦您开始必须通过此数据进行查找，排序或过滤，它可能会得到非常快，非常难看。有了这个说法，我对名称/值对和XML有很强烈的意见，但唉，没有一个是正面的。如果您必须以这种方式存储您的数据，并且是可以是完全有效的业务/设计决策，那么我会建议您长时间努力寻找如何使用和访问您需要存储在数据库中的数据在将来。根据将如何使用每种方法来衡量利弊，并挑选最容易管理和维护的方法。 （不要挑选最容易实现的那个，你会支持它的时间比你写的要长得多。）
（它很长，但the "RLH" essay是一个典型的名称/值对的例子横行。）
（哦，如果你使用它，看看SQL Server 2008中的“稀疏列”选项。听起来不像你需要什么，但你永远不知道。）
感谢您的反馈。实际上，我们刚刚在这个主题上举行了一次小型会议，并且因为您列出的许多原因而决定使用表格而不是XML。现在只需要负责使用EAV模式。 – 2011-03-21 18:39:10
（Bookarking现在这个问题，所以我可以稍后再回来，upvote所有的“你真的不想这样做”的答案） – 2011-03-21 14:25:28
这两个选项中，我真的不想做的是哪一个？ ;-) – 2011-03-21 14:26:40
将新列添加到产品表时出现什么问题？这些属性仅与产品的某个子集相关吗？ – tster 2011-03-21 14:48:42