我正在考虑一个新的应用程序的新数据库结构,并意识到我们需要一种有效的方式来存储历史数据.我想要别人看看,看看这个结构是否有任何问题.我意识到这种存储数据的方法可能非常好地被发明(我几乎可以肯定),但是我不知道如果它有一个名字,一些谷歌搜索,我尝试没有产生任何东西.
问题：
假设您有一张订单表,并且订单与放置订单的客户的客户表相关.在正常的数据库结构中,您可能会期望这样：
orders ------ orderID customerID customers --------- customerID address address2 city state zip
很简单,orderID有一个customerID的外键,它是客户表的主键.但是,如果我们要在订单表上运行报表,我们将把客户表加入订单表,这将返回该客户ID的当前记录.如果订单放置时,客户地址不同,随后更改.现在我们的订单不再反映客户地址的历史,在订单的时候.基本上,通过更改客户记录,我们只是更改了该客户的所有历史记录.
现在有几种方法可以解决这个问题,其中一种是创建订单时复制记录.我所想到的是,我认为这样做会更简单一些,这可能会更加优雅,并且随时更改记录也增加了额外的好处.
如果我这样做了一个结构呢？
orders ------ orderID customerID customerHistoryID customers --------- customerID customerHistoryID customerHistory -------- customerHistoryID customerID address address2 city state zip updatedBy updatedOn
请原谅格式,但我想你可以看到这个想法.基本上,这个想法是,客户随时更改,插入或更新,customerHistoryID将被递增,客户表将使用最新的customerHistoryID进行更新.现在的订单表不仅指向customerID(它允许您查看客户记录的所有修订版本),而且还指向customerHistoryID,它指向记录的特定修订.现在,订单反映了创建订单时数据的状态.
通过将更新和更新的列添加到customerHistory表中,您还可以看到数据的“审核日志”,以便您可以看到谁进行了更改以及何时执行.
一个潜在的缺点可能是删除,但是我不是很担心这个需要,因为没有什么应该被删除.但是,尽管如此,通过使用activeFlag或类似的东西也可以取决于数据的域来实现相同的效果.
我的想法是,所有的表将使用这个结构.正在检索历史数据时,它将使用customerHistoryID与历史记录表相结合,以显示该特定顺序的数据状态.
检索客户列表很简单,只需要在customerHistoryID上加入客户表.
任何人都可以从设计的角度来看待这种方法的任何问题,或者为什么这是糟糕的性能原因.记住,无论我做什么,我需要确保历史数据被保留,以便随后的记录更新不会更改历史记录.有没有更好的办法？这是一个已知的想法,有一个名字,或任何文件吗？
感谢任何帮助.
更新：
这是一个非常简单的例子,我真的会拥有.我的真正的应用程序将有“订单”与几个外键到其他表.原产地/目的地位置信息,客户信息,设施信息,用户信息等.有几次建议,我可以将信息复制到订单记录中,我已经看到这样做了很多次,但这将导致数百列的记录,这在这种情况下真的是不可行的.
解决方法
orders ------ orderID customerID address City state zip customers --------- customerID address City state zip
编辑：如果您喜欢的列数量变高,您可以将其分离出来,但您喜欢.
如果您使用其他选项并使用历史记录表,则应考虑使用bitemporal数据,因为您可能需要处理历史数据需要更正的可能性.例如,客户将当前的地址从A更改为B,但您还必须更正现有订单中当前要履行的地址.
另外如果您使用MS sql Server,您可能需要考虑使用索引视图.这将允许您交易一个小的增量插入/更新perf减少大量选择增加.如果您不使用MS sql服务器,您可以使用触发器和表复制这些.
