MySQL中的版本控制树结构
考虑一个分层文件系统，其中每个文件夹维护一个版本历史记录(即名称和其他属性可能会更改)。我需要在MySQL 5.1中实现这一点，但是将来的版本可能会移植到SQL Server 2012。
我知道数据库中的树结构有几种选择：
- 邻接表
- 嵌套集 (可能会导致极慢的插入)
- 嵌套间隔 (复杂的东西，需要对递归的支持.)
这些技术以前曾在StackOverflow上讨论过。但是，我的问题增加了问题的另一个维度，因为我需要维护每个节点的历史记录。需要维护的数据可以看作是属性的列表。例如，姓名，日期，类型..。
一些前提
- 该数据库将同时处理5-10个客户端.
- 该树预计将增长到1000-5000个父节点(有任意数量的叶)。
- 节点可以在任何时候插入。
- 节点/叶可能永远不会被更新或删除。Insted中，将维护版本历史记录。
- 不允许对节点进行重组。(不过，如果可能的话，这将是很好的！)
- 多个客户端可以同时添加/修改树节点。因此，客户端需要不断地重新读取树结构(不需要实时更新)。
- 重要性顺序:可追溯性(关键)、性能、可伸缩性。
Q:对于树结构及其版本控制的节点数据，首选的技术是什么？示例很受欢迎，但不是强制性的。
回答 1
Stack Overflow用户
发布于 2013-04-04 06:30:12
版本控制是非常棘手的，因为您正在处理时变数据，而且您建议的数据库(或我所知道的任何其他数据库)都不支持简单地执行此操作。
请阅读在SQL中开发面向时间的数据库应用程序；这本书可能已经有15年的历史了，但是问题基本上没有改变。
您提到“可追溯性(关键)”的事实表明，您希望得到正确的结果。
在考虑一份简单的报告以显示传家宝时，您需要考虑的问题是，您需要知道：
- 使用今天的数据，树看起来像什么(是的，很明显)
- 根据上周的数据，这棵树现在的样子
- 一周前这棵树是什么样子的，用今天的数据
- 一周前这棵树是什么样子的，利用上周的数据
- 一周前这棵树是什么样子的，使用前一周的数据
您所面临的问题是因为您正在处理的是时变数据，它是在与它正在建模的现实世界过程不同的时间更新的，它本身可能处理的是时态数据。不管怎样，读读这本书。
如果这是一个非问题(即树是静态的)，那么@didierc在他的注释中是正确的，树的节点可以引用外部版本控制表。但是，如果您还需要存储有关继承本身的版本控制信息，则如果天真地实现(使用任何模型)，此方法将无法工作。
为了给出一个具体的例子，考虑一个简单的树在1/1/13 - A->B->C上有效，如果在1/2/13上改变为A->D->B->C。如果你在1/3/13上运行一个查询，引用1/2/13，你想检索哪一棵树？
祝好运
https://stackoverflow.com/questions/12529534
复制相似问题
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号