我正在构建一个模块来编辑节点的层次结构。您可以将其视为一个非常大的目录结构，其中包含许多级别的嵌套目录和文件。层次结构的节点存储在关系数据库表中。唯一的区别是没有文件夹/目录之类的东西。所有节点都具有相同的特征。所以一个节点有一个父节点，它也是一个节点。而且只有一个根节点，一个节点只能有一个父节点，所以没有多层次结构。
表列：
node_id [bigint] 非空
名称 [nvarchar(50)]
parent_node_id [bigint]
叶节点 [bit]
目标是找出一种方法来编辑一个层次结构，而无需用户互相踩脚。我们要么必须设计版本控制架构来解决冲突，要么使用某种锁定机制（悲观或乐观）来防止其他人编辑作为整个层次结构中某个给定父节点的祖先（或子树）的一部分的节点树。如果我们执行锁，那么每个使用编辑器的人都需要不断刷新他们的树才能看到其他人的变化。
只有三个功能需要担心。只有一个用户允许在主树中编辑节点/对象。将新创建的子树拖放到主树中。将主树中的子树拖放到主树中的另一个节点中，从而使删除的子树成为该节点的子节点。
我认为这种架构与管理文件夹和文件的操作系统架构没有什么不同。这通常是如何在成千上万的用户上完成的？我宁愿使用锁定机制而不是使用版本控制来降低复杂性。我只是不确定最好的方法是什么。
到目前为止，这是我的计划：
如果一个节点正在被编辑，在保存发生并且数据库即将更新记录之前不要锁定它。数据库进行更改后，将其解锁。如果其他人试图在数据库进行更改的同时编辑记录，请不要告诉用户它已被锁定。让数据库处理记录/节点上的锁。
如果新的子树被拖入主树的父节点，则锁定新的父节点。然后插入新记录并更新根父节点以指向主树父节点。然后通知所有客户端更新他们的主树。因此，在删除发生后，所有锁定都发生在数据库端。
如果一个现有的主树父节点被拖到一个现有的主树父节点中，并成为一个子节点，那么我们应该锁定旧的父节点（成为新的子节点）并锁定新的父节点。然后更新新子节点的父节点。然后更新所有客户端（所有用户）并更新他们的主树。因此，在删除发生后，所有锁定都发生在数据库端。