在高度规范化的数据库中选择表数据的通用版本控制策略

对于长篇大论的标题感到抱歉,但要求/问题是相当具体的.

参考下面的示例(但非常简化)结构(在伪造的SQL中),我希望能够更好地解释它.

TABLE StructureName {
  Id GUID PK,
  Name varchar(50) NOT NULL
}

TABLE Structure {
  Id GUID PK,
  ParentId GUID,                 -- FK to Structure
  NameId GUID NOT NULL           -- FK to StructureName
}

TABLE Something {
  Id GUID PK,
  RootStructureId GUID NOT NULL  -- FK to Structure
}

可以看出,Structure是一个简单的树结构(不担心为这个问题排序孩子).StructureName是翻译系统的简化.最后,"Something"只是引用树根结构的东西.

这只是需要进行版本化的许多表中的一个,但是这个表在大多数情况下都是一个很好的例子.

需要对Structure表的名称和/或树"布局"的任何更改进行版本化.以前的版本应始终可用.

似乎有一些可能性来解决这个问题,比如复制整个结构,但大多数方法都会导致一个"松散"的参照完整性.例如,如果遵循这种方法,则必须复制"Something"记录,假定根结构将是新记录,并且具有新ID.

其他可能解决方案的途径是研究Wiki如何处理这个问题或进一步研究如何正确处理版本控制系统的工作方式.

目前,我觉得如何以通用方式继续这一点感到有点无能为力.

任何想法将不胜感激.

谢谢

leppie

一些快速的想法:

完整副本:创建结构的副本,但是对于每个表version_id,向PK和所有FK 添加一列; 因此,您可以使用完整的参照完整性创建生命数据的副本.

亲:轻松查询历史记录

con:大量(复制的冗余数据)

更改副本:仅复制实际更改的内容以及valid_from/ valid_todata.

亲:复制的数据量很小

con:难以查询,因为必须间隔加入

变化:这适用于两种方案.您可以将当前记录保存在与旧版本相同的表中,而不是创建结构的副本,而是将其标记为当前记录.

pro:数量较少的表格,更容易混合历史和当前信息

con:正常操作在更大的表上运行,这将导致性能影响

审计日志:根据您的实际要求,只需创建如下审计跟踪就足够了:

id,  timestamp,  changed_table,  changed_column,  old_value,  new_value,  changed_by

transaction,  table_change,  changed_column