数据库建模中的计划与实际实体答案

【问题标题】：Planification vs Actual Entities in database modeling数据库建模中的计划与实际实体
【发布时间】：2021-07-24 14:54:33
【问题描述】：

作为小型初创公司的开发人员工作的一部分，我最近一直在从事多个项目，到目前为止，我已经多次遇到过这个问题。当您有一个由计划和后来的实际事物组成的实体时该怎么办？

举个例子，让我们假设一家公司想要记录他们所有的安全演习。当然，这意味着有人会为演习制定计划，也许会为演习选择日期和时间以及参加演习的人员。这说明了实体的规划。一段时间后，演习实际发生了，因此我们想要记录实际发生的日期和时间（为简单起见，我们假设计划中的人总是与实际参与者相同）。

例子：

我在很多其他的实际例子中看到了同样的情况，培训计划和实际培训，定期维护和实际维护，估计预算和实际费用等。有时我们通过使用布尔属性来解决这个问题，例如在一个实体中“计划”、“完成”、“完成”或“批准”。其他时候，我们使用单独的实体，但尚未就更好的选择达成共识。

您认为解决此类问题的最佳选择是什么？一个 PlanificationEntity 和一个实际的实体？只是一个布尔值？

【问题讨论】：

【解决方案1】：

这完全取决于计划中的内容，因此没有单一的答案。

在您的情况下，演习似乎会随着时间的推移积累信息并改变状态。每次您进行计划时似乎都有一个单独的演习，并且只执行该演习。您可能只想保留当前状态，但我通常希望保留转换表以了解何时发生。

变体可能是课程或培训，其中有标准培训。这可能存储为一个实体（比如trainings）。然后，您将拥有一个 training_schedule 表，其中可能包含过去和未来的日期——以及唯一的 ID。然后参与者将被链接到training_schedule。

另一种变化是预算与实际值。在这种情况下，预算在很多方面都是它自己的实体，您希望随时间命名并保留它。实际值会累积，您想比较它们。那将是一个不同的数据模型，因为可能同时存在多个有效预算（当年的原始预算和基于已经发生的实际情况的更新预算）。

【讨论】：

感谢您的回答！我明白了，即使只是一个过渡，也建议为此设置一个单独的实体？我认为主要问题与所有示例都具有 1 对 1 关系这一事实有关，并且在创建数据库表时它们“可能”成为单个表。可能不是最好的方法，很难。正如我从您的回答中了解到的，将它们作为单独的实体仍然更好。
@JuanDrago 。 . .不，可能不是。您可能需要某种转换表来记录状态更改。或者有多个日期/时间来指示状态何时在单个记录中更改。这取决于日期的“固定”程度以及演习是否可以恢复到较早的状态。

【解决方案2】：

计划实体应称为配置实体。比如drillConfiguration和drill。 DrillConfiguration 可以具有钻孔日期和时间以及任何其他属性。而钻头是具有用于钻头配置的外键属性的实际钻头。那是我的两分钱

【讨论】：