c# - NHibnerate 数据设计建议

Question

在对映射一对一关系进行一些研究时，我遇到了一些陈述，这些陈述让我质疑我的一些数据库设计决策。

基本上我有一些类似于以下的实体:

个人、联系人、家长

联系人和 parent 都是人。一个人可以是联系人、 parent 、两者或都不是。

我提出的数据库设计为这三个实体中的每一个都有一个表，并且所有三个表共享一个主 ID (PersonID)。从数据库设计的角度来看，这似乎是一种表示数据库及其关系的良好规范化且性能合理的方式(至少对我而言)。

此时，我开始编写 C# 类和 NHibnerate 映射来表示这些实体。我能找到的最自然的映射方法是使用映射。其他选项(一对一、一对多等)似乎要求我向表中添加一个或多个不必要的 FK。在浏览 NHibernate 文档时，我偶然发现了以下声明:

This feature is often only useful for legacy data models, we recommend fewer tables than classes and a fine-grained domain model. However, it is useful for switching between inheritance mapping strategies in a single hierarchy, as explained later.

我的问题是:

A) 我是否违反了这条原则？ B) 如果是这样，我将如何更好地设计这个系统？

此声明是否建议我将所有 Person/Contact/Parent 字段集中到一个表中(包含许多可为 null 的字段)？还是我不知何故错过了重点？

因为这是我可以从头开始设计表/类的罕见情况，所以我想把它做好。在此先感谢您的帮助!

编辑:关于我希望上述数据库设计如何工作的更多信息:

基本思想是每个人在人员表中都有一条记录。相关表中记录的存在/不存在决定了此人是否是 parent 、联系人等......这似乎强制执行一对一关系并允许快速查询/连接(共享主 ID 将是一个每个表中的聚类 PK)。

编辑:感谢大家的帮助。当我设计这个系统时，我并没有真正充分考虑可查询性，所以我将转向类似于 Jamie Ide 和 hlgem 建议的解决方案。我发现所有答案都有帮助。总而言之，共享主键看起来会导致 C# 端的对象模型出现一些问题。

Answer 1

您的数据库设计需要一些工作；这是我的建议。

很高兴您知道 Contact 和 Parent 都可以是 Persons；但是，您需要 Contact 和 Parent 具有不同的主键。您可以强制要求他们在联系人表和父表中都具有父 ID，外键引用人员表中条目的人员 ID。

所以 Person 表应该有一个唯一的主键(它的 ID)和任何其他相关的列。 Contact 表应该有自己唯一的主键(它的 ID)，一个对 Person 表(Person 表中的 ID)和任何其他相关列的不可为 null 的外键引用。 Parent 表应该有自己唯一的主键(它的 ID)，以及对 Person 表(Person 表中的 ID)和任何其他相关列的不可为空的外键引用。

这应该可以解决您的映射问题。如果需要，您可以使用 View “重组”您的个人/ parent /联系人“星座”(相关表的集合)。