我正在构建一个模块来编辑节点的层次结构。你可以把它想象成一个非常大的目录结构，有很多层次的嵌套目录和文件。层次结构的节点存储在关系数据库表中。唯一的区别是没有文件夹/目录这样的东西。所有节点具有相同的特征。一个节点有一个父节点，父节点也是一个节点。而且只有一个根节点，一个节点只能有一个父节点，所以没有多层次结构。
表列:node_id [bigint] not null
名称[nvarchar(50)]
Parent_node_id [bigint]
Leaf_node [bit]
目标是找出一种方法来编辑一个层次结构，而不会让用户彼此踩到对方的脚趾。我们要么必须设计一个版本控制体系结构来解决冲突，要么使用某种锁定机制(悲观或乐观)来防止其他人编辑整个层次结构树中某个给定父节点的祖先(或子树)的节点。如果我们执行锁，那么每个使用编辑器的人都需要不断刷新他们的树来查看其他人的更改。
只有三个特征需要担心。在主树中编辑节点/对象只能由一个用户允许。将新创建的子树拖放到主树中。将主树中的子树拖放到主树中的另一个节点中，从而使被拖放的子树成为该节点的子树。
我不认为这种架构与管理文件夹和文件的操作系统架构有什么不同。对于成千上万的用户来说，通常是怎么做的呢?我宁愿使用锁定机制，而不是使用版本控制来降低复杂性。我只是不确定最好的方法是什么。
这是我到目前为止的计划:
如果一个节点正在被编辑，不要锁定它，直到保存发生，数据库即将更新记录。在数据库进行更改后，解锁它。如果其他人试图在数据库进行更改的同时编辑记录，不要告诉用户它被锁定了。让数据库处理记录/节点上的锁
如果一个新的子树被拖到一个主树父节点，锁定新的父节点。然后插入新记录并更新根父节点以指向主树父节点。然后通知所有客户端更新它们的主树。所以在drop发生后，所有的锁都发生在数据库端。
如果一个现有的主树父节点被拖拽到一个现有的主树父节点，并成为一个子节点，那么我们应该锁定旧的父节点(成为新的子节点)并锁定新的父节点。然后更新新子节点的父节点。然后更新所有客户端(所有用户)并更新它们的主树。所以在drop发生后，所有的锁都发生在数据库端。
对于1，您可以只使用乐观锁。(你当前的方法意味着"最后的数据覆盖现有的")。
关于2和3 -似乎拖放可以通过重新链接节点来实现，所以你可以让它更容易一点-没有过多的数据复制。
在这种情况下，你可以引入一个link lock，它锁住了链路的两端。这可以防止"源"节点同时移动到其他"目标"节点;它还可以防止突然的"目标"节点移动，这对于客户端来说应该是一个惊喜。