SQL Server中具有历史记录的树结构

时间:2011-03-04 14:35:58

标签: sql sql-server tree history

我不确定这是否是一个重复的问题,但我在这个问题上找不到任何内容。

在表中存储树结构的最佳方法是什么,能够存储该结构中的更改历史记录。

感谢您的帮助。

更新:

我有员工表,我需要在表格中存储分支,部门,部门,子部分的结构。 我需要在员工分支机构,部门存储历史信息,以便能够检索员工的分支,部门,部门,子部分,即使结构已经更改。

更新2:

有一个解决方案可以在结构的每个变化中将整个结构保存在历史表中,但这是最好的方法吗?

更新3:

还有订单表。我必须在每个订单上存储员工的职位,分支,部门,部门,子部门等。这是存储历史的主要原因。它会经常使用。换句话说,我应该能够显示过去每天的数据库数据。

更新4:

也许使用hierarchyid是一种选择?

如果重命名节点怎么办?如果我需要旧订单上的旧名称,我该怎么办?

4 个答案:

答案 0 :(得分:3)

我认为你正在寻找这样的东西。它提供了完整的树形结构。这用于目录,但它可以用于任何事情:部门,部门,部门等。

历史是独立的,最好是在考虑历史之前先了解一下节点结构。对于任何表的历史记录,只需要在PK中添加DateTime或TimeStamp列即可。历史记录存储在当前行的图像之前。

使用纯SQL执行诸如(a)解析树的路径和(b)查找在某个时间点当前的相关历史行的功能。使用MS,您可以为(a)使用递归CTE,或者在存储过程中编写更简单的表单。

对于(b),我将实现表的派生版本(Node,Department,whatever),它返回相关时间点当前的行;然后将其用于(a)的历史版本。

每次更改时都无需复制和保存整个树结构。

如果您需要任何澄清,请随时提出问题。

数据模型

▶Tree Structure with History Data Model

不熟悉关系建模标准的读者可能会发现▶IDEF1X Notation有用。

答案 1 :(得分:2)

根据历史信息的使用方式,将决定您是需要时间解决方案还是仅需要审计解决方案。在时间解决方案中,您将存储给定节点在其给定位置应用的日期范围,并通过使用当前日期和时间查询活动节点以便报告层次结构来派生“当前”层次结构。说这是一个复杂的解决方案是轻描淡写。

鉴于我们正在谈论员工层级,我的赌注是审计解决方案就足够了。在审核解决方案中,您有一个用于当前层次结构的表,并将更改存储在可访问的其他位置。应该注意,“其他地方”不一定需要是数据。如果对公司层次结构的更改很少,那么您甚至可以使用严重低技术的解决方案来创建公司层次结构的报告(或一系列报告),并以PDF格式存储这些报告。当有人想知道去年五月的层次结构是什么时,他们可以找到相应的PDF打印输出。

但是,如果希望审计跟踪是可查询的,那么您可以考虑类似SQL Server 2008的更改跟踪功能或执行类似操作的第三方解决方案。

请记住,“最好”的问题比结构本身还要多。有一项成本效益分析,说明需要多少工作量与其提供的功能。如果利益相关者需要在任何时刻查询层次结构并且它经常波动(不想在那里工作:))那么时间解决方案可能是最好的,但实施成本会更高。如果层次结构不经常更改并且不需要进行粒度审计,那么我倾向于只是定期存储层次结构的PDF。如果确实需要查询更改或需要进行细粒度审计,那么我将查看审计工具。

Change Tracking

快速搜索,这里有几个第三方审核解决方案:

ApexSQL

Lumigent Technologies

答案 2 :(得分:1)

有几种方法,但是我会说有限的信息使用单表与父关系,对于历史记录,你可以简单地实现对表的审计

UPDATE:根据您的新信息,我不会使用单个表数据存储,看起来您的层次结构比简单的树复杂得多,看起来您看起来还不错在进入部分和子部分之前,特别是在顶部定义结构的节点;所以多表关系可能更合适;

就审计表而言,有大量资源可以找出最适合您的方法,每行和每列审计等。

答案 3 :(得分:1)

有一点需要注意的是,你不能对树结构进行历史记录。它总是只会增长,永远不会变小。

节点的用途是什么?他们的数据可能会改变。

用于eaxample网站。

/ A / B / C

永远存在。 A也可以是文件夹,也可以是文件。后来可能是一个人,一个墓碑(目前没有数据)作为c。但树本身永远不会改变。

然后,添加一个版本号,并为每个节点添加一个历史记录/使用列表(节点类型),其中包含start和可能(可以为null)结束版本。

显示版本X的代码可以轻松地构建当前的“真实”树。

要支持节点移动,请使用“rehook”类型,表示noe已移至此版本的其他项目。

瞧。