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

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

参考下面的示例（但非常简化）结构（伪 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”只是引用树的根结构的东西。

这只是需要进行版本控制的众多表之一，但这一个对于大多数情况来说都是一个很好的例子。

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

似乎有一些可能性可以解决这个问题，例如复制整个结构，但大多数方法都会导致“失去”引用完整性。例如，如果遵循这种方法，则必须复制“Something”记录，因为根结构将是一条新记录，并且具有新的 ID。

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

目前，我觉得有点不知道如何以通用的方式进行此操作。

任何想法将不胜感激。

Thanks

leppie

一些快速的想法：

完整副本：创建结构的副本，但为每个表添加一个version_idPK 和所有 FK 列；因此，您可以创建具有完整引用完整性的生命数据副本。

• pro：方便查询历史记录
• 缺点：大量（复制的冗余数据）

更改副本：只复制实际更改的内容以及valid_from / valid_to data.

• 优点：复制的数据量低
• 缺点：很难查询，因为必须按时间间隔加入

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

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

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

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

您可以将其扩展到完整的表结构：

transaction,  table_change,  changed_column

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

I wrote 关于各种版本控制方法的博客，但请注意：它是德语的。