数据库设计：随着时间的推移，我如何处理跟踪目标与实际值？答案

【问题标题】：Database Design: How do I handle tracking goals vs. actuals over time?数据库设计：随着时间的推移，我如何处理跟踪目标与实际值？
【发布时间】：2017-07-11 08:16:06
【问题描述】：

这不完全是一个编程问题，因为我没有编写代码的问题，而是一个数据库设计问题。我需要创建一个应用程序来跟踪销售目标与一段时间内的实际销售额。问题是，一个人的目标可以改变（我们最多说每天）。

此外，一个位置可以有多个具有不同目标的代理，需要为该位置添加在一起。

我考虑过基本上运行一个定时任务来将每个代理的每日目标保存到一个字段中。似乎多年来这将是大量数据，但它可以让我简单地查询一个日期范围并将所有每日目标相加以获得该日期范围的目标。

否则，我想我可以简单地编写更改（即 3 月 2 日 - 每周 15 次销售，4 月 12 日，每周 16 次销售），这将是更少的数据，但更多的编程工作来确定基于时间查询的目标.

我假设这可能有一个最佳实践 - 任何人？

【问题讨论】：

标签： database database-design graphql

【解决方案1】：

为您的目标设定一个日期范围。范围的开始是您设定目标的时间。范围的结尾从最大整理日期开始（通常为 9999-12-31，具体取决于您的数据库）。

将此视为“直到永远”或“直至另行通知”。

当您想知道在特定日期生效的目标时，您的WHERE 子句中会包含这样的内容：

...
WHERE effective_date <= @AsOfDate
  AND expiry_date > @AsOfDate
...

当您更改目标时，您需要两个操作，首先更新现有记录（如果存在）并将expiry_date 设置为新的截止日期。然后插入一条新记录，其中effective_date 为新的截止日期，expiry_date 为永远（例如'9999-12-31'）

这将为您带来以下好处：

最少行数
没有计划的进程来拍摄每日快照
轻松检索到某个时间点的有效记录
现成的更改审核日志

【讨论】：

嗨@JoelBrown - 我唯一的问题是关于运行报告的复杂性。如果我在一年的过程中运行历史报告，那么我必须找到每次有人改变他们的目标，计算从那次改变到下一次改变之间的时间，然后计算那个时间段的总数，然后做同样的事情一年中的所有其他时间段并将它们相加。如果我只是简单地保留每日总计，我可以只查询该时间段内的所有每日目标，添加它们，然后完成。所以我只是想确认一下，您认为保持数据库更简单更好吗？
@JustinHandley 您经常会发现用于数据维护的最佳数据结构与用于报告的最佳数据结构大不相同。术语“数据仓库”是指为报告而构建的数据库。在这种数据库中，规范化规则被排除在外，因为数据仓库基本上是只读的。它代表历史，因此无法更改（这是过度简化）这取决于您的目标。如果两者都需要，那么您可能需要两种数据结构来满足您的所有需求，并使用简单、可靠的代码。