sql - 数据库设计 : should nested objects have their own table?

Question

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

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

我考虑过两种布局方式:

• Jobs 和 Subjobs 每个都有自己的表。
  • 这似乎是“不错的设计”，因为我在 Job 中引入列的唯一目的不是为了与自身嵌套。
  • 编写 Web 应用程序的代码有点痛苦，因为 Job 和 Subjob 必须有两个独立的 Controller / View 集，尽管它们是相同的在属性中。
  • 如果引入无限嵌套，从设计角度来看意义不大。
• Jobs 和 Subjobs 在同一张表上。 Jobs 只是被赋予一个可为 null 的 parent_job_id 属性，如果它是一个 Subjob，则该属性为非 null。
  • 对无限嵌套有意义。
  • 编写 Web 应用的代码不再那么痛苦。
  • Job 表中引入了一个奇怪的嵌套属性，它与 Job 的实际属性无关。

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

Answer 1

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

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

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

层次引用:

• StackOverflow - What are the options for storing hierarchical data in a relational-database
• Louis Davidson - Presentations - How to Optimize a Hierarchy In SQL Server - Presentations & Demo Code