我有一个现有的，成熟的架构，我们需要添加一些新的Product属性。例如，我们有Products.Flavor，现在需要添加新的属性，如Weight，Fragrance等。而不是继续扩大Products表，我正在考虑其他几个选项。首先是一个新的Attributes表，它实际上是一个用于任意属性的属性包，以及一个ProductsAttributes表来存储特定产品属性的映射（和值）。这是实体 - 属性 - 值（EAV）模式，因为我已经了解它。另一个选项是向Products表中添加一个名为Attributes的新列，其类型为XML。在这里，我们可以在不添加新表的情况下随意向任何产品实例添加属性。
每种方法的优缺点是什么？我正在使用SQL Server 2008和ASP.NET 4.0。
答案 0 :(得分：3)
这是（imho）经典数据库设计问题之一。也许，称之为“属性creep”，一旦你开始，总会有另一个属性或属性要添加。他们的关键决定是，使用数据库提供的基本工具（表和列）将数据存储在数据库中以构建和格式化数据，还是以其他方式存储数据（XML和名称/值对）是最常见的替代品）。简而言之，如果您以不同于DBMS系统支持的形式存储数据，那么您将失去DBMS系统管理，维护和使用该数据的能力。如果您只需要将其存储为“blob数据”（将其全部存入，将其全部输出），这不是什么大问题，但是一旦您开始必须通过此数据进行搜索，排序或过滤，它就可以获得非常难看。
话虽如此，我对名称/价值对和XML确实有很强的看法，但唉，没有一个是积极的。如果你必须以这种方式存储你的数据，是的，这可能是一个完全有效的业务/设计决策，那么我建议你仔细查看如何你需要存储在数据库中的数据将来会被使用和访问。根据每种方法的使用方法，权衡每种方法的优缺点，选择最容易管理和维护的方法。 （不要选择最容易实现的那个，你将支持它的时间比你写的要长很多。）
（很长，但the "RLH" essay是运行amok的名称/值对的经典示例。）
（哦，如果你正在使用它，请查看SQL Server 2008的“稀疏列”选项。听起来不像你需要的，但你永远不知道。）