可疑的SQL关系

Question

我正在经历一个复杂的课程，目前正在使用实体框架代码优先方法构建MVC应用程序。我对用于项目的数据库模式感到困惑。

正如您所看到的，证券与其相关表格之间的关系似乎是一对一的，但当我意识到没有外键来关联这两个子表时它们会出现混乱。它们似乎共享相同的主键列。

之前的视频使证券模型类抽象出来，以便＆＃34; Stock＆＃34;和＃34; MutualFund＆＃34;模型类从中继承并包含所有相关数据。然而，对我而言，使用几个外键似乎可以做同样的事情。

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

Answer 1

在ORM和EF术语中，此设置称为"Table per Type"继承范例，其中每个子类有一个表，一个基类表，主键在子类和基类之间共享

e.g。在这种情况下，Securities_Stock和Securities_MutualFund是Securities基类/表的两个子类（可能是抽象的）。

关系将为0..1 (subclass) to 1 (base class) - 即每个基表Securities_MutualFund行中只存在Securities_Stock或Securities中的一条记录。

基表上通常还有一个鉴别器列来指示join到哪个子类表，但这似乎不是这样的。

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

要回答您的问题，两个子类instance表之间没有FK的原因是因为每个instance（具有唯一ID）将只存在于其中一个子类表 - 同一个Security不可能既是共同基金又是共享基金。

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

如果在Stock和Mutual Fund之间添加了外键，则无法在表格中插入新行。

完整模式通常如下所示：

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)
);