我们正在构建联系人管理应用程序。每个联系人都是一个节点。如果发现2个或更多联系人是重复的，我们希望能够将它们合并到单个节点中。此外，我们希望维护合并前的节点状态，以便我们可以根据需要撤消合并（*）。
我们建议通过创建一个新节点并使用“merged_into”边缘将旧节点链接到它，并将status属性设置为“removed”来建模。
现在我们有两个选择：
我们将两个合并节点中的所有现有边复制到新节点
我们没有。
选项2提供了更简单的数据结构，但它使我们的所有查询更加复杂。因为我们必须通过潜在的多级合并节点返回以获取所有边缘
选项1会使查询保持相同，但会引入许多额外的边缘。
我们还在考虑创建完整数据库副本的第三个选项，其中所有合并节点都已折叠。即只是当前联系人的视图。这需要与主数据库保持同步。
对于处理此问题的最佳方法提出任何意见/建议表示感谢。
我还想建议一个新的“崩溃”查询功能，这将使选项2更容易工作....这样的事情：
从10＃12中选择输出（“attend_class”）崩溃（“merged_into”）
会折叠指定的边，直到没有进一步的出站“merged_into”边缘，从而检索附加到前一个（预合并的）节点的所有边
亲切的问候
斯瓦米·凯瓦拉答案 0 :(得分：3)
我认为这个问题取决于您期望合并发生的频率。 如果他们很少使用选项1并运行一个不时删除剩余部分的cron作业。
如果他们经常使用选项2，那么合并/取消合并要快得多。 你仍然应该使用一个＆＃34;清理＆＃34;您的数据并通过边缘移动到合并的节点（一旦明确它们将不会被取消合并）。
顺便说一句： 如果节点的属性相同（除了它们的_key）并且不必合并，那么你可以通过一个简单的技巧逃脱：
每当节点A应与节点B合并时，在连接A和B的集合merged中添加边缘，并将标记B标记为＆＃34;删除＆＃34;。
然后修改查询以检查集合merged中的节点是否存在边缘，将它们放入查询的起始顶点集中。如果要撤消合并，只需删除此边缘即可。如果要将其他边添加到合并节点，则可以将其添加到任一节点。即使已经添加边缘，这也可以取消合并节点。