当使用符合6NF原则标准化的数据库时，您将如何存储历史属性数据？
比方说我们从@PerformanceDBA获取this example但是有以下额外要求：
我们需要存储所有产品的历史数据 能够只输入日期并获得该属性的快照 那个特定时间的产品。
更实用的例子：
假设上面示例中的磁盘和CPU是虚拟的，用户可以随意更改磁盘容量。我们如何改变数据库，以便我们可以在过去的任何时间（当然是在创建日期之后）检索给定磁盘的属性，同时保持5NF视图足够快。
我正在考虑的事情
感谢任何帮助！
编辑：我知道时态数据库的概念，但问题是对于我正在使用的数据库引擎（postgresql），时态扩展尚未完全实现。关于如何在没有时态数据库的情况下实现此目的的任何建议？
答案 0 :(得分：9)
最近批准的SQL：2011标准结合了一些功能，使您能够比以往更好地处理此类问题。
并不是说你能够在时间领域做你想做的所有事情，但是所引入的确实是一个相当重要的改进。
请注意，只有一家供应商在他的SQL产品中对这些功能提供了合理的支持，另外一家可能正在努力，第三家已为其客户打开了投票渠道。
www.linkedin.com上还有一个“时间数据”讨论组，专门针对您的主题。
EDIT试图解决“如何在没有时态数据库的情况下实现这一目标的任何建议？”
不要只为模型添加单个日期/时间类型列。第一个原因是你给出的，第二个原因是这个解决方案也是新标准推广的解决方案，并且它将有助于过渡到支持新功能的引擎。
因此，添加一个开始日期和结束日期/时间列。不要使它们无法使用。新标准要求其具有时间特征。如果最终MIT（时刻）仍未知，请使用适用时间类型的最高值，例如9999-12-31
您无需“为每个属性创建单独的历史记录表”。同样可能具有“单个实体表”，其保持“整个实体发生的历史”。缺点是很难查询某个特定属性发生 ACTUAL 更改的时间（因为对于任何属性的任何更改都会获得新的历史行，可能会复制大多数相同的属性值的属性）。 “单一表”很可能是对空间的渴望消费者，“每个属性的独立历史”可能是查询CPU时间的热切消费者。这将是一种平衡行为，而且平衡恰恰取决于您的具体情况。
不要“在表格中添加索引的'当前'列”。首先，当你的引擎有它们时，它们不会帮助你转换到新功能，其次，Y / N列是非常糟糕的鉴别器，因此非常不适合索引。我宁愿将你的start或end-mit添加到索引中，可以期望它们为“当前”行提供相同的胜利，并且当需要查询那些时，可以更好地赢得非当前行
对于数据库约束的执行，例如临时密钥中的时间段中的非重叠以及时间RI中包含时间段，您完全依靠自己。按优先级顺序在触发器或SPROC或应用程序代码中编写所需的代码。
这更有帮助吗？