我需要存储一组实体，其中有几个专门的版本。它们具有一些共同的属性，但是专门的属性包含特定于该实体的属性。
解决方案 数据存储区是一个关系DBMS，这不用于讨论：-)具体来说，它是Microsoft SQL Server 2005。
我可以轻松地为公用属性创建一个表，然后为每个专用版本创建一个表。但是，很可能以后必须将新实体添加到解决方案中，并且我不想同时维护对象模型和数据库架构。
另一个想法是创建一个表
reading(<common properties>, extended_properties)
并具有extended_properties扩展属性的某种序列化字段。我在想JSON或XML。我很可能会使用ORM框架，但我尚未决定。无论哪种方式，来自的专用实体的对象表示都reading可以公开一个字典，{extended_property_name, value}其中包含来自extended_properties字段的已解析键/值对。
extended_properties
{extended_property_name, value}
从此http://msdn.microsoft.com/zh-cn/library/ms345117(SQL.90).aspx中，我收集到XML字段以及用于这些字段的模式，它们给出了DBMS内部类型化XML的概念。同样，涉及该extended_properties字段中XML内容的查询也可以考虑这些内容。
http://msdn.microsoft.com/zh-cn/library/ms345117(SQL.90).aspx
我想要的是 对我的解决方案建议的反馈，主要是带有reading扩展属性表和序列化的建议。
此外，我意识到与基于键/值的存储相比，这是关系DBMS的局限性之一。但是，肯定必须有一些建模技术来适应这种情况。
任何反馈，我们将不胜感激！
安德斯（Anders）不会放弃任何完整性或硬度，例如类型安全性。
（响应即将到来）。
@安德斯 不，一点也不好，子类型很好（问题是您使用的是哪种形式，缺点/缺点是什么）。不要放弃任何强度或完整性，类型安全性或支票或DRI。您选择的表格将需要额外的支票和一些代码（取决于您的平台）。
这个主题经常出现，但是寻求者总是有一个狭窄的视野。我不断从不变的集合中做出相同的陈述（子集）。想法是评估所有选项。所以我在写文档。不幸的是，这花费了更长的时间。也许有4页。还没准备好发布。但是图表已经制作完成，我想您已经准备就绪，您可以立即使用它。
警告：经验丰富的项目施工工程师专用 道路不适合大篷车或高Eek因数的读者
链接到“正在构建的文档”中的“四个替代数据模型”。为地板上的混乱而道歉；我会尽快清理的。
▶对于不熟悉关系数据库建模标准的任何人，请链接至IDEF1X Notation◀。
它们都是关系型的，具有完全的完整性。
6NF选项。当今的Relational（SQL）不提供对6NF的支持；它不禁止它，只是不提供5NF➔6NF结构。因此，您需要建立一个小的目录，有些人称之为“元数据”。实际上，它只是标准SQL目录（sys表）的扩展。在每个选项中都对所需的控制级别进行了建模。
从根本上说，EAV可以正确地完成，具有完全的控制和完整性（类型安全性，声明性引用完整性），而不是通常的混乱情况。
