我正在寻找有关设计围绕版本化数据的数据模型的最佳方法的一些输入。会有一对多和多对多的关系,这些关系都可以随着版本的变化而变化。
我正在寻找一些不同的策略,最终目标是有效比较,如果可能的话只存储增量。
我正在寻找有关设计围绕版本化数据的数据模型的最佳方法的一些输入。会有一对多和多对多的关系,这些关系都可以随着版本的变化而变化。
我正在寻找一些不同的策略,最终目标是有效比较,如果可能的话只存储增量。
这实际上是一个相当困难的问题。
版本控制对象很容易。它们之间的版本连接并没有那么多——您必须做出一些设计决策。例如:
最重要的是,大多数“支持”表可能也需要“版本感知”。
如果我是你,我可能会从以下起点开始:
OBJECT 和 CONNECTION 之间的符号是“类别”(又名继承、子类、泛化层次结构等)。
这种设计背后的基本思想是支持“快照”、“恢复”和“增量”功能:
查询将是这样的:
假设您必须放置对象 A、B 和 C,其中 A 是 B 和 C 的父对象:
generation: 0
A0
/ \
B0 C0
添加新对象 D:
generation: 0 1
A0
/ | \
B0 C0 D1
修改A和C并删除B:
generation: 0 1 2
A0
A2
/ | \
B0 C0 D1
B2* C2
(*) OBJECT_VERSION.DELETED is true
将 C 从 A 移动到 D:
generation: 0 1 2 3
A0
A2
/ |* \
B0 C0 D1
B2* C2 |
C3
ETC...
这种设计对不一致删除的异常情况是开放的:数据库不会保护自己不连接已删除和未删除的对象,或者在不删除连接的情况下将其中一个对象演变为已删除状态。在检查两个端点之前,您不会知道连接是否有效。如果您的数据是分层的,您可以使用“可达性模型”来代替:如果可以从某个根对象访问对象,则不会删除该对象。您永远不会直接删除该对象 - 您只需删除与它的所有连接。这对于文件夹/文件或类似的层次结构非常有效,您从“顶部”开始并向下搜索直到找到所需的对象。
“不可变”连接的替代方法是从 OBJECT_VERSION 继承 CONNECTION_VERSION 并将 PARENT_ID/CHILD_ID 放在那里,使用识别关系来确保正确建模菱形依赖关系。如果您需要跟踪移动历史,这可能很有用。
当然,这些只是粗略的笔触,我希望你能找到自己的方式......