mysql - MySQL 中的版本控制树结构

Question

考虑一个分层文件系统，其中每个文件夹 都维护一个版本历史记录(即名称和其他属性可能会更改)。我需要在 MySQL 5.1 中实现它，但 future 的版本可能会移植到 SQL Server 2012。

我知道数据库中的树结构有几种选择:

• Adjacency List
• Nested Set (可能导致插入速度极慢)
• Nested intervals (复杂的东西，需要支持递归...)

以前在 StackOverflow 上讨论过这些技术。但是，我的问题增加了另一个维度，因为我需要维护每个节点的历史记录。需要维护的数据可以看作是一个属性列表。例如。姓名、日期、类型……

部分场所

• 该数据库预计可同时处理 5-10 个客户端。
• 该树预计会增长到 1000-5000 个父节点(具有任意数量的叶子)。
• 可以随时插入节点。
• 节点/叶子可能永远不会被更新或删除。 Insted，维护版本历史记录。
• 不允许重组节点。 (尽管如此，如果可能的话，这会很不错!)
• 多个客户端可以同时添加/修改树节点。因此，客户端需要不断地重新读取树结构(不需要实时更新)。
• 重要性顺序:可追溯性(关键)、性能、可扩展性。

问:树结构及其版本控制节点数据的首选技术是什么？SQL 示例值得赞赏，但不是强制性的。

Answer 1

版本控制非常棘手，因为您要处理随时间变化的数据，而您建议的数据库(或我所知道的任何其他数据库)都没有本地支持来简单地执行此操作。

请阅读 Developing Time-Oriented Database Applications in SQL ;这本书可能已有将近 15 年的历史，但问题基本上没有变化。

您提到“可追溯性(至关重要)” 的事实表明您将希望做到这一点。

当考虑一个简单的报告来显示继承权时，您需要考虑的问题是您是否需要知道:

• 树今天的样子，使用今天的数据(是的，很明显)
• 树现在的样子，使用上周的数据
• 一周前树的样子，使用今天的数据
• 树在一周前的样子，使用上周的数据
• 一周前树的样子，使用前一周的数据

您面临的问题是因为您正在处理随时间变化的数据，这些数据的更新时间与它正在建模的真实世界过程不同，它本身可能正在处理时间数据。无论如何，请阅读本书。

如果这不是问题(即树是静态的)，那么@didierc 在他的评论中是正确的，树的节点可以引用外部版本控制表。但是，如果您还需要存储关于 heirachy 本身的版本控制信息，那么如果天真地实现(使用任何模型)，这种方法将不起作用。

举一个具体的例子，考虑一棵在 1/1/13 有效的简单树 - A->B->C。如果这在 2013 年 1 月 2 日更改为 A->D->B->C。如果您在 2013 年 1 月 3 日运行查询，回溯到 2013 年 1 月 2 日，您想要检索哪棵树？

祝你好运