数据库设计：嵌套对象应该有自己的表吗？答案

【问题标题】：Database design: should nested objects have their own table?数据库设计：嵌套对象应该有自己的表吗？
【发布时间】：2017-11-07 12:12:13
【问题描述】：

我对数据库设计有点陌生，所以我想要一些关于如何最好地布置我当前表的指针。

我有一张桌子Jobs 可以做各种工作。用户可以创建Subjobs。 Subjob 有一个 Job 作为父级。 Subjob 具有与Job 相同的所有属性，但其中一些是只读的，而对于Job，它们都是读/写的。一个Job 可以有多个Subjobs。目前，可能只有一层子作业，但我希望将来能够灵活地允许Subjobs 的无限嵌套。这些对象将通过 MVC Web 应用程序进行交互。

我考虑了两种布局选项：

Jobs 和 Subjobs 都有自己的表格。
- 这似乎是“好设计”，因为我在 Job 中引入列的唯一目的不是与自身嵌套。
- 编写 Web 应用程序有点麻烦，因为 Job 和 Subjob 必须有两个单独的控制器/视图集，尽管它们的属性相同。
- 如果引入无限嵌套，从设计的角度来看就没那么有意义了。
Jobs 和 Subjobs 在同一张桌子上。 Jobs 只是被赋予了一个可空的parent_job_id 属性，如果它是Subjob，则它是非空的。
- 对无限嵌套有意义。
- 编写 Web 应用程序的痛苦更少。
- Job 表中引入了一个奇怪的嵌套属性，它与 Job 的实际属性无关。

关于如何处理这个问题的任何建议？有没有我没有考虑过的其他设计模式？我正在使用 Entity Framework 6 Code First，如果这很重要的话。

【问题讨论】：

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

【解决方案1】：

如果您没有描述具有多个级别的层次结构，则第一个选项很好，但您确实如此。您所描述的模式通常称为邻接列表，它在您描述第二个选项时存储。

存储层次结构的其他一些选项是：

嵌套集（更复杂的实现但可能更快的查询没有递归）。
物化路径（存储层次结构路径的字符表示，例如文件存储系统）
邻接表的修改/辅助表（平面表、桥表）
自定义实现，如HierarchyId

层次结构参考：

【讨论】：

干得好。我正在写一个几乎相同的评论，但这比我要列出的要强大得多。 :)
@SeanLange 谢谢！几乎是对stackoverflow.com/q/4048151/2333499 的简要介绍，并附有一些一般性观察。