问数据库设计-四级父子关系

EN

我的雇主也想要子报价-这意味着个人可以引用他自己的努力，独立于主报价。每次发生ProjectRevision时，子报价都必须重做，并且必须保留所有旧版本和Subquotes以供将来参考。

这在表模式中会是什么样子？在我看来，这本质上是一个四级列表:一个项目包含一个修订版列表，每个修订版包含一个SubQuotes列表，每个修订包含一个任务列表。

假设不存在子引用可能与多个用户相关的任何实例：

SUBQUOTES表

• SUBQUOTE_ID，pk
• PROJECT_REV_ID，fk
• USER_ID，fk
• supporting columns

我没有看到对现有数据模型进行任何其他必要的更改。

修订的定义是什么？根据这一点，我可能会选择temporal design。因此，项目表将存储修订，而不是具有多个修订的项目。您可以通过添加一个列来跟踪以前的主键、修订开始日期和修订结束日期来完成此操作。进行修订时，旧Id将从新记录链接回。新记录的开始时间为now，结束日期为空。旧记录将有一个空的结束日期，但也需要更新到现在。旧记录仍将指向所有旧的子引号。

Project
-----------------
Id
RevisisedFromId
RevisionStartDate
RevisionEndDate
RevisionNumber (optional, this can be calculated)


SubQuote
-----------------   
Id
ProjectId (when a new revision is made, this will still point to the old revision)

在这个模型中，Project表有一个代理ProjectID主键(自动递增)和一个NaturalKey，它必须对项目是唯一的，并且不能改变(比如"Pave My Driveway 25764")。

发布新版本时，将在Project表中插入新行，并且ProjectID将递增，但NaturalKey将被复制。修订号被更新，新行中的RevisionStatus字段被设置为"current“，前一行中的字段被设置为"expired”。此时，所有任务都指向旧的修订版本，所有引号都指向这些任务--因此历史记录将被保留。使用NaturalKey很容易跟踪修订(收集所有项目is )。

当一个任务被“延续”到一个新的修订版本时，它被复制到一个新的行中，其中包含一个新的主键和指向新ProjectID的外键。这样，历史也会被保留下来。

所有引号现在都必须为新任务完成，或者复制到新行中，并使用指向新TaskID的外键。这样，引用历史也会被保留下来。

​

​