在数据库中存储历史记录

Question

关于在数据库中存储历史记录，使用DateEnd（例1）或持续时间（例2）更好吗？

或者请随意提出另一种最有效的方法。

如果一个证明是正确的方法，我应该对其中一个例子做出其他改变吗？正在使用的数据库是MySQL，虽然我不认为它与这里的方法有关。

Answer 1

如果您有开始日期和结束日期，您可以随时（或应该始终能够）计算持续时间。如果您有开始日期和持续时间，您可以随时（或应该始终能够）计算结束日期。

您还可以记录所有三个并强制执行行约束，使其不会“不匹配”。

然而，“结束日期”数据的一种非常频繁的用法是过滤掉“不是最新”的行：类似于WHERE END_DATE＆gt; CURRENTSYSTEMDATE（）。如果您有这种用法，那么可能不建议“遗漏”结束日期。

Answer 2

对此有两种看法 - 首先，业务领域是什么？在您的示例中，您使用了“订阅” - 这些通常以“每月”，“每周”等形式出售。所有其他条件相同，我希望我的数据库尽可能与业务概念保持一致。您甚至可以创建“subscription_type”表，并从类型中导出描述的持续时间。

这经常与您的数据库执行需求发生冲突。从这个角度来看，我将弄清楚最常见的查询是什么，看看是否可以使用最少量的类型转换或计算来使数据库设计工作。例如，如果您可以请求dateEnd＆lt;，那么查找订阅在给定日期到期的所有记录会更容易（并且可能更快）。 targetDate，而不是通过将持续时间添加到开始日期来计算日期。

Answer 3

我会存储结束日期而不是持续时间。您可以在需要时计算持续时间。似乎更有意义的是存储测量点而不是测量值。

Answer 4

诸如持续时间之类的派生值不需要存储在数据库中。

捕获行的历史记录的方法在某些情况下会起作用，但是为了真正捕获所有行的所有更改，您可能需要另一个表，例如subscription_hist，它将通过插入和更新订阅时的触发器进行更新。然后你必须只跟踪last_modified_date和last_person_changed_by。其他一切都可以衍生出来。通过这种方式，您可以看到该行随时间发生的变化。我没有任何图片需要澄清，但如果仔细实施，这种方法可以实现数据的完整时间点恢复，以及维护历史信息。