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

Question

抱歉标题冗长，但要求/问题相当具体。

引用以下示例(但非常简化)结构(伪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是一个简单的树结构(不用担心 child 排序的问题)。 StructureName 是一个翻译系统的简化。最后，'Something' 只是引用树的根结构的东西。

这只是需要进行版本控制的众多表中的一个，但在大多数情况下，这个表都是一个很好的例子。

需要对结构表的名称和/或树“布局”的任何更改进行版本控制。以前的版本应该始终可用。

似乎有几种可能性可以解决这个问题，例如复制整个结构，但大多数方法都会导致“松散”参照完整性。例如，如果采用这种方法，则必须复制“Something”记录，因为根结构将是一个新记录，并具有一个新 ID。

其他可能的解决方案正在研究 Wiki 如何处理这个问题，或者更进一步，看看正确的版本控制系统是如何工作的。

目前，我对如何以通用方式进行此操作感到有些无能。

任何想法将不胜感激。

谢谢

乐皮

Answer 1

一些快速的想法:

完整复制:创建结构的副本，但为每个表添加一个 version_id 列到 PK 和所有 FK；因此，您可以创建具有完整参照完整性的生命数据副本。

• pro:查询历史方便
• 缺点:大量(复制冗余数据)

更改副本:仅复制实际更改的内容，以及 valid_from/valid_to 数据。

• pro:复制的数据量较小
• 缺点:很难查询，因为必须按时间间隔加入

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

• 优点:表格数量较少，历史和当前信息更容易混合
• 缺点:正常操作在更大的表上运行，这将对性能产生影响

审计日志:根据您的实际需求，创建这样的审计跟踪就足够了:

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

您可以将其扩展为完整的表结构:

transaction,  table_change,  changed_column

• pro:通用，因此很容易为大量表实现
• 缺点:如果您需要在给定时间重建一组记录的状态，查询将成为一场噩梦

我写了a blog about various approaches to versioning ，但请注意:它是德语的。