我对数据库设计有些陌生，所以我想要一些关于如何最好地布置我当前的表的指示。
我有一个表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。
最佳答案
如果您不描述具有多个级别的层次结构，那么第一个选项很好，但您是。您所描述的模式通常称为邻接列表，它在您描述第二个选项时存储。
存储层次结构的其他一些选项是:
- 嵌套集(更复杂的实现，但可能更快的无递归查询)。
- 物化路径(存储层次结构路径的字符表示，例如文件存储系统)
- 邻接表的修改/辅助表(平面表、桥接表)
- 自定义实现，例如 HierarchyId
层次引用:
关于sql - 数据库设计 : should nested objects have their own table?，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/44390652/