Database 6NF和历史属性数据

当使用符合6NF原则的规范化数据库时，您将如何存储历史属性数据

例如，我们从@PerformanceDBA中获取，但有以下额外要求：

我们需要存储所有产品的历史数据，我们应该 只需输入一个日期并获取 产品在那个特定的时间

一个更实际的例子：
假设上面示例中的磁盘和CPU是虚拟的，用户可以随意更改磁盘容量。我们如何改变数据库，以便能够在过去任何时候（当然是在创建日期之后）检索给定磁盘的属性，同时保持5NF视图足够快

我正在考虑的事情

• 向每个属性表添加一个时间戳列“changedate”（这将导致一个非常复杂的查询，每个属性表都有一个子查询和连接）
• 为每个属性表创建一个单独的*历史记录表（可能会产生大量的表，因为我们有大约70个属性分布在20种产品类型上）
• 另外：在每个属性表中添加一个索引“current”列，以加快5NF视图的速度

感谢您的帮助

---

---

编辑：我知道时态数据库的概念，但问题是，对于我正在使用的数据库引擎（postgresql），时态扩展尚未完全实现。关于如何在没有时态数据库的情况下实现这一点，您有什么建议吗？

最近批准的SQL:2011标准包含了一些功能，可以让您比以往更好地处理此类问题

并不是说你可以在时间舞台上做任何你想做的事情，但是你所做的确实是一个相当显著的改进

关于它的一个很好的介绍是在

请注意，只有一家供应商对其SQL产品中的这些功能提供了合理的支持，另一家可能正在开发，第三家为其客户打开了投票渠道

在www.linkedin.com上还有一个“时态数据”讨论小组，专门讨论你手头的主题

编辑试图解决“关于如何在没有时态数据库的情况下实现这一点的任何建议？”

不要只在模型中添加一个日期/时间类型列。第一个原因正如您所说的，第二个原因是此解决方案也是新标准所提倡的解决方案，并且它将有助于过渡到支持新功能的引擎

因此，添加开始和结束日期/时间列。不要使它们中的任何一个为空。新标准对其时间特性提出了这一要求。如果结束MIT（时刻）仍然未知，请使用适用时间类型的最高值，例如9999-12-31

您不需要“为每个属性创建单独的历史记录表”。同样可以有一个“单一实体表”来保存“整个实体事件的历史记录”。缺点是很难查询某个特定属性何时发生了实际更改（因为对任何属性的任何更改都会获得新的历史行，可能会复制大多数属性的相同属性值）。“单个表”可能是空间的急切消费者，“每个属性的单独历史记录”可能是查询CPU时间的急切消费者。这将是一种平衡行为，而平衡的准确位置取决于你的具体情况

不要在表中“添加索引的“当前”列”。首先，当您的引擎拥有新功能时，它们不会帮助您过渡到新功能，其次，Y/N列是非常糟糕的鉴别器，因此非常不适合索引。我更愿意将您的开始或结束mit添加到索引中，它们可以为“当前”行提供相同的胜利，为非当前行提供更好的胜利，只要您需要查询这些行

至于数据库约束的实施，比如时态键中的时间段不重叠，以及在时态RI中包含时间段，那么您就完全靠自己了。在触发器、存储过程或应用程序代码中按首选项的降序编写所需的代码

---

这更有帮助吗？

谢谢，我现在发现了postgresql（）的临时扩展，这似乎就是我要寻找的。一些更实际的例子会有所帮助。只是警告你——我一直没有历史记录表，在我的“实体”的每一行上都使用“从”和“到”日期。这是我犯的最大的错误，它把这个项目变成了一场噩梦。在你提到的PerformanceDBA的指导下，我才明白数据库到底是什么（也就是说，不仅仅是一个存储对象的桶）。此后，我使用更传统的方法（历史表/视图）重写了该项目，并且在各个方面都做得更好。好的，没有太多的争论，但深入细节需要大量的文档。这篇文章让我开始改变我对数据库的总体看法（从软件工程师的角度，到DBA的角度）：-我并不是说做建议的事情是错误的（使用“from”和“to”没有历史表格），但对我来说，这造成了一个大混乱，我再也不会走这条路了。