问数据库设计-存储当前和过去事件的体育场容量

EN

三种选择：

选项1

创建一个历史表，存储可以更改体育场的所有数据。这也可以包括它的名称，尽管它的位置可能已经设置好了。让我们称之为"StadiumHistory“。然后，您的进度表将使用此表作为其FK。StadiumHistory表将有一个FK到体育场表，该表唯一地标识了体育场及其位置。

选项二

问问自己：“我的最终目标是什么？”答案可能是“创建一个可以快速查询的系统，其中包括团队/目标/ etc的聚合功能在内的计算可以非常快地执行，从而使我能够根据各种因素确定可能的结果或预测未来的结果，或者审查过去的趋势等”。

如果这是您的最终目标，您可能希望将您的3NF数据库保持在上面，并定期将其导出到另一个具有维度规范化的数据库--一个数据仓库。然后你的体育场变成一个维度表，可能扩展到“位置”，你的结果是一个事实表。此维度表将包含您在体育场中指定的所有字段的值(经常重复)。事实上，您可以扩展“位置”表，然后将当天的天气信息、场地状况、人群出席情况等包括在内。

这种方法具有许多长期优势，但需要一个新的数据库(开发)和一个适当的ETL过程来加载它。我的经验告诉我，如果您的数据库记录了历史信息，并且希望开始聚合用于趋势分析的信息，您将最终构建这个系统。如果您发现自己为所有内容编写历史表，您将发现在当前数据库中很难维护这些接口。

选项三

忘记任何改变的事。在任何一天记录容量真的很重要吗？如果不是，不要担心记录体育场容量的历史。您的数据库只包含最新的体育场信息。

这是最简单的选择--这意味着您不必更改数据库设计。

一个类似问题的答案是这里，它讨论版本规范形式。

我不指望一个体育场会经常改变，但是跟踪这些变化是个好主意，尤其是为了报道目的。可能会发生更多的事情是对不同的运动进行周期性的修改。为棒球而设的体育场很可能与为足球而设的同一体育场有不同的容量。vnf的一个好特性是可以提前插入预定的更改。当前的容量将继续显示，直到预定的日期到来，或者如果“前瞻性”查询着眼于该日期之后的未来。