2

我们有 3 个相互关联的实体：

  • Foo 有很多附件
  • 酒吧有很多附件
  • 每个 Attachment 可以属于 Foo 或 Bar。

使用 建模的最佳方法是什么DbModelBuilder？

如果我们尝试：

modelBuilder.Entity<Foo>().HasMany(t => t.Attachments).WithOptional()
    .Map(m => m.MapKey("FOO_ID")).WillCascadeOnDelete(true);
modelBuilder.Entity<Bar>().HasMany(t => t.Attachments).WithOptional()
    .Map(m => m.MapKey("BAR_ID")).WillCascadeOnDelete(true);

这不是一个非常干净的数据模型： * 附件表将有两个 FK 列，一个用于每个可能的父实体（'FOO_ID'、'BAR_ID'）。如果我们增加需要附件的实体的数量，它会使表格膨胀。* 我们需要将后向引用设为可选，尽管附件总是附加到实体上。它不一定是Foo，也不一定是Bar。但是模式将允许所有 FK 设置为 NULL 的附件，尽管从业务视图来看它是无效的。* 理论上，一个 Attachment 可以同时链接到 Foo 和 Bar，这是无效的。

相反，我们可以将关系映射到联结表 'T_FOO_ATTACHMENT' 和 'T_BAR_ATTACHMENT'： * T_FOO_ATTACHMENT 具有Foo所需的外键 (FOO_ID) 和附件 (ATTACHMENT_ID) 所需的 FK。* T_BAR_ATTACHMENT 也一样

缺点： * 附件仍然可以链接到 Foo 和 Bar。* 一个附件甚至可以链接到多个 Foo，这也是无效的。理想情况下，我们可以使用流利的语法来添加防止这种情况的数据库约束。

4

1 回答 1

2

这不是一个非常干净的数据模型：附件表将有两个 FK 列，一个用于每个可能的父实体（'FOO_ID'、'BAR_ID'）。

但从关系的角度来看这是绝对正确的——如果你想与另一个表建立关系，你需要一个新的外键。

但是模式将允许所有 FK 设置为 NULL 的附件，尽管从业务视图来看它是无效的。理论上，一个附件可以链接到一个 Foo 和一个 Bar，这是无效的。

那是你的业务逻辑。对于您当前的模型，您必须在您的应用程序中强制执行它。

您正在寻找的是某种命名关系，其中Attachment不仅有 FK，而且还有相关表的名称。这是您在关系级别上无法实现的 - 它是数据级别（再次是业务逻辑），并且无法使用 EF 进行映射。

于 2012-06-04T14:18:08.503 回答