可疑的SQL关系

我正在学习pluralsight课程，目前正在学习使用实体框架代码优先方法构建MVC应用程序。我对项目中使用的数据库模式感到困惑

正如您所看到的，证券和它的关联表之间的关系似乎是一对一的，但是当我意识到没有外键来关联两个子表，并且它们似乎共享相同的主键列时，就会产生混淆

之前的视频对Securities模型类进行了抽象，以便“Stock”和“MutualFund”模型类从中继承并包含所有相关数据。然而，对我来说，似乎同样的事情也可以用几把外键来完成

---

我想我的问题是，这种链接表的方法在SQL或EF中有用吗？在我看来，为了为一个表创建一个新记录，所有表都需要一个新记录，这是我真正感到困惑的地方。

在ORM和EF术语中，这种设置被称为继承范式，其中每个子类都有一个表，一个基类表，主键在子类和基类之间共享

e、 g.在这种情况下，

Securities\u Stock

和

Securities\u MutualFund

是

Securities

基类/表（可能是抽象的）的两个子类

关系将是

0..1（子类）到1（基类）

-即每个基表

Securities

行只存在

Securities\u MutualFund

或

Securities\u Stock

中的一条记录

基表上通常还有一个鉴别器列，用于指示要将

连接到哪个子类表，但这里的情况似乎不是这样

使用外键强制子类与基表之间的引用完整性也是很常见的

为了回答您的问题，两个子类
实例
表之间没有FK的原因是因为每个
实例
（具有唯一Id）将只在其中一个子类表中-同一
证券
不可能既是共同基金又是股票

您是对的，为了添加新的具体
Security
记录，基本
Securities
表中都需要一行（必须首先插入，因为它们是从子类表到基本表的FK），然后将一行插入其中一个子类表中，以及其余的“特定”数据

如果在
股票
和
共同基金
之间添加外键，则无法在表中插入新行

完整模式通常如下所示：

CREATE TABLE BaseTable
(
    Id INT PRIMARY KEY, -- Can also be Identity
    ... Common columns here

   Discriminator, -- Type usually has a small range, so `INT` or `CHAR` are common
);

CREATE TABLE SubClassTable
(
    Id INT PRIMARY KEY, -- Not identity, must be manually inserted
    -- Specialized SubClass columns here
    FOREIGN KEY (Id) REFERENCES BaseTable(Id)
);