如何在CouchDB中存储树？
CouchDB Wiki的How_to_store_hierarchical_data页面描述了一种方法，但是作者对移动节点说:
这部分让我有些担心，因为有人可能
否则，您可能会在移动过程中添加新的子节点
子树，使新节点自己悬在子树中
不再存在。我不确定要避免的最佳方法
这样的问题。
面对如此大的问题，这真的是存储树木的最佳实践吗？
我正在考虑通过向每个节点添加parentId来实现我的树，这不好吗？
(我意识到它类似于this question，但是在移动节点时，那里接受的答案具有未指定的行为)
最佳答案
这是我很快将解决BlueInk的问题。目前，我正在使用实例化路径，并计划使用MapReduce动态生成站点 map (完整树)。
移动树的分支时，最好使用“all_or_nothing:true”进行Bulk Update:
然而...
全有或全无-要使用此模式，请将all_or_nothing: true包括为
部分要求。在验证失败的情况下，
文件将被保存。但是，它不会进行冲突检查，因此
即使会产生冲突，也会提交所有文档。
...因此您可能最终会遇到冲突，并且必须确保validate_doc_update不会完全阻止更改。
另一种选择是与更改“最终保持一致”。您可以执行批量更新而不使用 all_or_nothing，并继续通过客户端代码处理MapReduce结果中的每个项目，直到它们全部被移动为止。不过，由于有人可能想将其移回原处，因此这可能非常冒险。
无论采用哪种方法保留其以前位置的历史记录，都应谨慎处理，以防出现问题。
我看到的parent_id唯一的麻烦是构建项目完整路径所需的请求数量。尽管除了使用_list键的一些简单MapReduce结果外，还可以使用[parent_id, _id]。构建_list函数并非易事，但应该可行。
我已经测试了其中一些方法，但是还没有完全充实它。如果您在上述任何一条道路上都走得更远，我很想听听您的进度/发现。
关于tree - 在CouchDB中存储树的最佳实践？ (移动节点必须可靠)，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/8722400/