我不确定这是否是一个重复的问题,但我找不到关于这个问题的任何东西。
在表中存储树结构的最佳方法是什么?它能够存储该结构中更改的历史记录。
谢谢你的帮助。
更新:
我有员工表,我需要存储部门、分区的结构。在桌子上。我需要存储员工部门,部门的历史信息,以便能够检索员工的部门,部门,分区,即使结构已经改变。
更新2:
对于结构中的每一次更改,都有一个将整个结构保存在历史表中的解决方案,但这是最好的方法吗?
更新3:
还有Orders表。我必须在每一份订单上存储员工的职位、部门和其他部门。这是存储历史的主要原因。它将被经常使用。换句话说,我应该能够显示每一天的db数据。
更新4:
也许使用层次结构是一种选择?
如果一个节点被重命名了怎么办?如果我需要旧订单上的旧名字,我该怎么办?
发布于 2011-03-04 16:02:47
根据历史信息的使用方式,将决定您是需要时态解决方案还是只需要审核解决方案。在时态解决方案中,您将存储给定节点应用于其给定位置的日期范围,而“当前”层次结构是通过使用当前日期和时间查询活动节点以报告该层次结构来派生的。说这是一个复杂的解决办法是轻描淡写的。
考虑到我们讨论的是员工等级制度,我敢打赌,审计解决方案就足够了。在审核解决方案中,您有一个用于当前层次结构的表,并将更改存储在其他可访问的地方。应该注意的是,“其他地方”不一定需要数据。如果对公司层次结构的更改很少发生,那么您甚至可以使用一种非常低技术的解决方案,创建公司层次结构的报告(或一系列报告),并以PDF格式存储这些报表。去年5月,当有人想知道层次结构是什么样子时,他们可以找到相应的PDF打印输出。
但是,如果希望审计跟踪是可查询的,那么您可以考虑类似于Server 2008的更改跟踪功能或类似的第三方解决方案。
记住,“最好”的问题比结构本身更重要。有一个成本效益分析,多少努力是需要与它提供的功能。如果涉众需要在任何时候查询层次结构,并且它经常波动(可能不想在那里工作:),那么时间上的解决方案可能是最好的,但实现成本会更高。如果层次结构变化不频繁,并且不需要粒度审计,那么我倾向于定期存储层次结构的PDF。如果确实需要查询更改或需要粒度审核,那么我将查看审核工具。
通过快速搜索,这里有几个第三方审计解决方案:
发布于 2011-03-07 08:20:17
我想你是在找这样的东西。它提供了完整的树结构。这是用于目录,但它可以用于任何东西:部门,等等。
历史是分开的,最好是在考虑历史之前先把你的头和节点结构联系起来。对于任何表的历史记录,只需在PK中添加一个DateTime或TimeStamp列。历史记录存储在当前行的图像之前。
诸如(a)解析树的路径和(b)查找在某个时间点上当前的相关历史记录行等函数使用纯SQL执行。使用MS,您可以为(a)使用递归CTE,也可以在存储的proc中编写更简单的表单。
对于(b),我将实现表的派生版本(Node,Department,不管怎样),它返回相关时间点上当前的行;然后将其用于(a)的历史版本。
不需要每次更改时都复制和保存整个树结构。
如果你需要澄清的话,随时可以问问题。
数据模型
不熟悉关系建模标准的读者可能会发现◀很有用。
发布于 2011-03-04 14:47:12
有几种方法,但是,由于您的信息有限,我要说的是使用带有父关系的单一表,对于历史记录,您可以简单地实现表的审计。
更新:基于您的新信息,我不会使用单一的表数据存储,您的层次结构看起来比简单的树要复杂得多,而且看起来您的结构中有一些定义良好的节点,特别是在进入部分和子部分之前,在顶部;所以多表关系可能更适合;
至于审计表,有足够的资源来找出哪些最适合您,还有每一行和每列的审核等等。
https://stackoverflow.com/questions/5195108
复制相似问题