将历史存储在数据库中

关于在数据库中存储历史记录，使用DateEnd（Ex。1）还是Duration（Ex。2）更好？或者请随意甚至建议另一种最有效的方法。将历史存储在数据库中

如果证明是正确的方法，我还应该对其中一个示例做出其他更改吗？ DB正在使用的是MySQL，尽管我不认为它对这里的方法有影响。

enter image description here

2011-03-19 swisscheese

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

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

来源

2011-03-21 13:03:30

现在你让我思考更多。我将不得不查看一些事情，看看SubscriptionType表是否可以满足我的需求。“这经常与您的数据库执行需求冲突”是因为您对第一段的回应，因此我应该远离这样做？这里的重要性在于跟踪结束日期，让用户知道什么时候需要重新启动。例如30天（任何增量/秒）通知并记录访问限制的过期账户。当然，其他内部问题也会完成，但是要考虑到同样的基本概念。 – swisscheese 2011-03-22 04:14:24

是的，性能问题往往与模拟业务领域的愿望相冲突。就你而言，除非你有数百万用户，否则我不会认为这是一个重大问题。如果你想创建提醒等，我会考虑将它们放入一个“提醒”表中，并具有状态以跟踪它们是否已被采取行动 - 如果有必要，你可以保持跟踪甚至是提醒，或者在人们更有可能回应的日子里发送出去（周末可能比周一晚）。 – 2011-03-22 09:36:47

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

来源

2011-03-19 02:08:47 dugas

如果使用持续时间，实际上是在丢失信息 - 从测量点到测量始终是可能的，但通常不可能从测量重新创建测量点。 – 2011-03-20 17:44:12

派生值（如持续时间）不需要存储在数据库中。

在某些情况下，您捕获行的历史记录的方法将会有效，但要真正捕获所有行的所有更改，您可能需要另一个表，类似subscription_hist，它将通过插入和更新触发器订阅。那么你将不得不跟踪last_modified_date和last_person_changed_by。其他一切都可以派生出来。这样你可以看到随着时间的推移发生了什么。我没有任何图片需要澄清，但是如果仔细实施，这种方法可以实现数据的完全时间点恢复以及维护历史信息。

来源

2011-03-19 02:54:21 dseibert

当您引入另一个如subscription_hist时，您提到的不仅仅是在数据库中创建重复项？或者你是否在金融体系中提出某种交易表格？ – swisscheese 2011-03-20 03:09:15

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

您也可以记录所有三个并强制执行行约束，以使它们不能“不匹配”。

但是，“结束日期”数据的一种非常常见的用法是过滤出“不是当前”行：类似于WHERE END_DATE> CURRENTSYSTEMDATE（）。如果你有这种用法，那么可能不建议“结束”结束日期。

来源

2011-03-21 12:40:58

将历史存储在数据库中

回答

相关问题