EF 中使用的自联接的最佳 sql 架构答案

【问题标题】：Best sql architecture for self-join used in EFEF 中使用的自联接的最佳 sql 架构
【发布时间】：2011-12-14 04:09:32
【问题描述】：

我有一个关于自联接的架构问题。

我有一个具有唯一 int 标识符的对象表。对象可以单独存在，也可以作为对象集合的一部分存在。集合在同一个表中表示为一个对象，但它的类型设置为集合。

例如

1 | ObjectName | IsolatedObject
2 | CollectionName1 | CollectionObject
3 | CollectionName2 | CollectionObject

之前的对象可能属于 0 个或多个集合，因此我有另一个存储映射的表

例如

2 | 1
3 | 1

已决定它们现在只能属于 1 个集合。我的问题是保留现有的额外表或更改对象表以具有存储唯一 ID 的 ParentID 字段是否更好？

这也与 EF 一起使用，因此关系映射会变得复杂。

提前感谢您的帮助。

【问题讨论】：

标签： sql-server tsql entity-framework database-design

【解决方案1】：

如果树中有多个分组，则您的映射表是一个很好的“可扩展”解决方案，但如果只有一个分组“级别”，那就过分了。 IE：如果一个对象集合可以有一个主人而不是其他任何东西的主人，那么一定要做一个自我加入。但是，如果 Object Collection 也可以是 master，那么您当前的映射解决方案会更好。

这样做的原因是“你需要走树吗？” 要返回 SQL 中的所有关系，您需要为每个级别（递归）重新查询表。如果只有独立对象可以是 Master，那么单个查询可以返回所有值

【讨论】：

【解决方案2】：

一般来说，在应用层强制执行完整性约束（也就是保持数据结构不变）不会立即给您带来问题，但从长远来看可能会。保留数据结构原样可能是一个很好的中间解决方案，直到最终用户可以修改所有数据以适应新的政策/要求，但我们在我的办公室里有一个说法，'如果数据可以放在那里，它会被放在那里';这意味着如果参照完整性允许，您可以打赌它会发生。

如果这是真正模拟需求的解决方案，我的建议是尽可能快地使用 ParentID/Self-referencing 模型；当然，这必须与预算、时间、用户承诺等平衡......

【讨论】：