4

考虑一个分层文件系统，其中每个文件夹都维护一个版本历史（即名称和其他属性可能会更改）。我需要在其中实现这一点，MySQL 5.1但未来的版本可能会移植到SQL Server 2012.

我了解数据库中的树结构有多种选择：

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

一些处所

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

问：树结构及其版本控制节点数据的首选技术是什么？SQL 示例很受欢迎，但不是强制性的。

4

1 回答 1

1

版本控制非常棘手，因为您正在处理随时间变化的数据，并且您建议的数据库（或我知道的任何其他数据库）都没有原生支持简单地执行此操作。

请阅读使用 SQL 开发面向时间的数据库应用程序；这本书可能有将近 15 年的历史，但问题基本没有改变。

您提到“可追溯性（关键）”这一事实表明您将要做到这一点。

在考虑仅显示继承关系的简单报告时，您需要考虑的问题是您是否需要知道：

  • 今天的树是什么样子，使用今天的数据（是的，很明显）
  • 使用上周的数据，树现在的样子
  • 使用今天的数据，树一周前的样子
  • 使用上周的数据，树一周前的样子
  • 树一周前的样子，使用前一周的数据

您面临的问题是因为您正在处理随时间变化的数据，这些数据的更新时间与其正在建模的真实世界过程不同，它本身可能正在处理时态数据。不管怎样，看书吧。

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

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

祝你好运

于 2013-04-04T06:30:12.140 回答