TPH - FK 在派生类上时如何满足 FK 约束？答案

【问题标题】：TPH - how to satisfy FK constraint when FK is on derived class?TPH - FK 在派生类上时如何满足 FK 约束？
【发布时间】：2016-08-17 23:00:49
【问题描述】：

假设我有抽象类 Person 的 TPH。然后我有从这个类派生的Girl 和Boy。 Girl 与 FavoriteMakeup 有关系，而 Boy 没有。插入Boy 记录时，如何满足Makeup 的FK 约束？还是 TPH 与仅限于派生类型的 FK 不兼容？

_{TPH：每个层次结构的表

FK：外键}

【问题讨论】：

标签： sql entity-framework database-design ef-code-first

【解决方案1】：

这里有两个不同的方面。让我们检查一下它们。

首先是关系 DBMS 中的外键是否可以具有空值。通常这是允许的：您可以同时拥有外键约束和非空约束或外键约束，同时属性可以为空。这是因为这两个约束通常被认为是独立的。例如，NULL 值可能意味着该值对于特定对象是未知的。

第二个方面与建模有关：通常，在像您的示例这样的情况下，虽然您可以使用“每个层次结构的表”方法，但这不是一个好的建模实践：您应该使用“Table per Type”（或使用 Microsoft 文档行话的 TPT）方法，因为所有 Girl 实体都与 Makeup 其他实体有关联，而 Boy 实体没有这种关联，而这一事实是实体的含义，而不是某些实体的特殊情况（如未知值）。

【讨论】：

由于代码重复，我很害怕 TPT。要么我开始重复代码（在模型定义中），要么混淆了我的业务逻辑。是否有“正确”的方式或者这是哲学上的？
在数据库世界中，实际上TPT方法被大量用于子类，您可以在所有数据库书籍中找到这一点。虽然你说你在重复代码？如果您的应用程序级别是在对象关系映射框架中编写的，那么通常的继承机制不会引入大量的代码重复。
我的意思是，如果我们看看 TPT 的含义，我将拥有三到四个 Payment 表，每个表共享约 50-70% 的列定义。这似乎比在一个地方执行与业务逻辑的数据关系不太理想……但我不知道。
在类型表中，唯一的公共列是指向表示超类的表的外键。不需要其他通用属性。