Database design 可支持专用属性的数据库架构

我需要存储一组实体，其中有几个专门的版本。它们有一些公共属性，但专用属性包含该实体的特定属性

解决 数据存储是一个关系型DBMS，这不用于讨论：-）具体来说，它是MicrosoftSQLServer2005

我可以轻松地为公共属性创建一个表，然后为每个专用版本创建一个表。但是，以后可能必须将新实体添加到解决方案中，我不想同时维护对象模型和数据库模式

另一个想法是创建一个表

reading(<common properties>, extended_properties)

读取（，扩展属性）

并使

扩展属性

字段成为扩展属性的某种序列化。我在考虑JSON或XML。我很可能会使用ORM框架，但我还没有决定。无论哪种方式，从

读取的专用实体的对象表示都可以公开一个字典
{extended_property_name，value}
，其中包含从
extended_properties
字段解析的键/值对

从这里，我收集到XML字段，结合这些字段的模式，给出了DBMS中类型化XML的概念。此外，涉及
extended_properties
字段中的XML内容的查询也可以考虑这些内容

我想要什么
对我的解决方案建议的反馈，主要是关于
读取
表和扩展属性序列化的建议

此外，我意识到，与基于键/值的存储相比，这是关系型DBMS的局限性之一。然而，必须有一些建模技术来适应这一点

非常感谢您的反馈
 我个人会选择“为公共属性创建一个表，然后为每个专用版本创建一个表”方法

理由：您说您的实现将在RDBMS中完成，这是不可协商的。好的
但是，在DB字段中转储非结构化、类似blob的内容（如序列化哈希表）违背了RDBMS的设计理念，因此，除非您同意将*extended_properties*字段视为不透明blob，就像gif或其他二进制对象一样，否则将严重影响效率

换句话说，忘记（高效地）查询“所有具有扩展属性COLOR=RED的对象”

您遇到的问题（在RDBMS中描述OO分类法）肯定不是新问题。请查看，以获得对选项的深入描述。
此技术在正确的设计和性能方面可能存在一些问题，但您似乎需要在灵活性方面做出妥协

不必为每个属性创建特定的表，甚至不必为每个属性创建一个新字段，您可以为唯一属性创建一个表（它将非常大）：

Unique_Property_ID
, FK_To_Some_Entity (Not sure what entity these link to: customers, bills, etc.) 
, Property_Type Not the data type but a link to a table describing this entity)
, Property_Value (Difficult to determine if all of your values will be of the same type: string, int, date, etc.)

例如：一家二手车经销商需要跟踪不同品牌和型号的附加组件（他们永远不知道他们会得到什么）。一些记录可能如下所示：

VehicleID   Property Type  Property Value
3           Sound System   Bose
3           Hybrid System  Battery
7           Starter Type   Hand Crank
7           Passenger Seat Rumble
9           Starter Type   Kick Start
9           Passenger Seat Side Car

每个集合属性类型的每个值都有自己的记录

另一个问题是，如果希望每个属性都表示为一列，则需要转置此表。
以下是SO中的五个示例。使用哪一个取决于您正在解决的实际问题和您的偏好

一般来说，我建议不要将数据序列化到DB字段中

如果实体的专用版本相对较少，您可以简单地使用以下示例中的子类型：，

对于较大的属性值，或者如果要动态定义属性（无模式更改），请查看观察模式的实现，如以下示例所示：，；或进入所谓的第六范式，如所述：。请注意，“观察模式”是第6版NF的简化版本。
这是gen spec设计模式的经典示例。Gen spec在关于对象建模的每个教程中都有介绍，因为它是通过继承来处理的。在有关关系数据建模的教程中经常会跳过它。但这是众所周知的

做一个关于“泛化-专业化-关系建模”的网络讲座。您将看到几篇关于如何为常规类设置一个表和为每个专用类设置一个表的文章。这些文章将帮助您进行外键设计。特别是，每个专用表的主键具有双重功能。它也是通用表的外键

如果您习惯于对象建模，这对您来说就不太熟悉了。但你会发现它工作得很好。大多数文章提供的解决方案都不是动态的，因此每次发现新的专门化子类时，都必须执行一些DDL
 安德斯，不要放弃任何完整性或硬度，如类型安全性

（即将有回应）

@安德斯。不，一点也不，子类型是可以的（问题是您使用哪种形式以及缺点/优点是什么）。不要放弃任何强度、完整性、类型安全、检查或DRI。您选择的表单需要额外的检查，可能还需要一些代码（取决于您的平台）

这个主题经常出现，但探索者总是有一个狭窄的视角；我从一个不变的集合中不断做出相同的语句（子集）。我们的想法是评估所有的选择。所以我在写一份文件。不幸的是，这需要更长的时间。大概4页。还没准备好发帖。但是图表已经完成了，我想你已经准备好了，你可以马上使用它

警告：仅限有经验的项目施工工程师

道路不适合大篷车或Eek系数高的读者

链接到正在构建的文档中的。道歉