为类似于概念、基于块（“段落”）或基于文档的应用程序选择数据库模型？

Question

1.问题

最近，似乎许多具有“无限”树结构的笔记管理器正在选择块模型（其中每个段落都是数据库中的一个条目），而不是文档或文件模型。

积木	文件
Notion Workflowy Remnote Dynalist Roam Research	Evernote 黑曜石 熊应用程序

如果您发现表中有任何错误，请告诉我。

我们已经开发一个与 Notion 非常相似的应用程序已有 8 个月的时间，也使用块模型，但我们正在考虑进行彻底的改变并切换到文档模型。目前 MongoDB 中的块结构如下所示：

_id: "61fd3ede7f6d2cc7a53ca669"
children: Array
    0: "61fd3ee87f6d2cc7a53ca66b"
    1: "61fd3ef37f6d2cc7a53ca671"
    2: "61fd3ef77f6d2cc7a53ca673"
backlinks: Array
type: "bullet"
parentPage: Array
    _id: "61fd3ede7f6e2ccra53ca664"
    userParent: "german-jablo"
    permisionParent: "edit, comment, read"
parentParagraph: "61fd3ede7f6d2cc7a53ca668"
content: "<p>This is a paragraph</p>"
isCollapsed: false
createdAt: 2022-02-04T14:57:34.280+00:00
updatedAt: 2022-02-04T14:57:59.585+00:00

许多页面都讨论了两种方法的差异（示例），尽管方式非常模糊，因此我们决定打开此线程来寻找问题的更科学答案。

我们的应用程序的特点

应用程序	可以作为文档打开的块	可以折叠或展开其子项的块
概念	页面类型块	切换类型块
工作流程	全部	全部
印象笔记	文件	没有任何
我们的应用程序	页面类型块	所有其他人

我们的应用程序有两种类型的“块”。页面类型（与 Notion 中一样，可以插入任何注释并在当前文档“内部”生成文档），以及其余块，相当于 Notion 中的“切换”块类型（即它们可以折叠或者可以展开其嵌套的子项）。

2.我们的尝试

在尝试回答我们的问题（哪种数据库模型最适合我们的应用程序）时，我们意识到答案可能是“视情况而定”。也许这两种模型在不同类型的操作或情况下都有优点或缺点。这就是为什么我们制定了这个比较表，描述了我们认为这两个模型对于每个操作的性能如何。

手术	积木	文件	明显的获胜者
获取页面内容	查找数据库中的所有段落。	在数据库中搜索文档。	文档
渲染页面内容**	递归地从段落构建树。您可以省略 isCollapsed 属性为 true 的段落的子项	渲染文档	文档
更新数据库中段落的内容	仅重写修改过的段落	整个文档被重写	堵塞
渲染非常大的文档的替代方案 *	当您滚动时（如 Workflowy 所做的那样）或当您展开折叠的子段落时，可以获取或呈现块。	我认为Grifds可以实现类似的行为，将文档分成更小的块并将它们零碎地整合在一起，但它不支持更新单个块，甚至整个文档。它还可能通过将 HTML 拆分为二进制格式来破坏 HTML。	堵塞
导入或粘贴内容	除了将剪贴板转换为 HTML 和/或对其进行清理之外，您还必须递归地设置具有树结构的段落。注意：Roam Research 例如支持以JSON 格式导入，但一般用户不会事先处理这种格式。	仅将剪贴板转换为 HTML 和/或清理剪贴板	文档
复制内容**	剪贴板必须经过清理和/或改造	默认正确**	文档
实时协作	在文档级别，可以使用一些基于树（Json）的库，例如Automerge，或者与段落级别的一些 CRDT 库结合使用。	可以使用tinymce解决方案。	领带？两者似乎都有各自的优点和缺点。

*渲染非常大的文档：大多数用户可能不会使用大于 250 kb 的笔记（考虑到多媒体文件在单独的集合中引用）。尽管如此，在文档模型中，问题还是出现了：我们如何以可管理的块加载、渲染或编辑大型文档？我们提出的一个想法是将尺寸较大的 HTML 文档分割成一定大小（以 kb 为单位）的部分，而不是将它们分割成段落。（它就像一种 Gridfs，允许您部分修改文件。）这是一个好主意吗？

** DOM 应该嵌套吗？为了能够折叠或展开嵌套的子段落，具有块模型的注释管理器以嵌套方式构建 DOM（段落位于 div 中、位于其父 div 内等）。然而，文档模型中的另一种选择可能是，当用户按下 Tab 时，只有该块（HTML 标记，例如<p>或<li>）被分配一个数字小于或等于 1 的属性，表示相对于前一个块的嵌套级别。这样，当您按 Tab 进行嵌套或按 Shift-Tab 取消嵌套时，您只需修改 HTML 元素的一个属性，而不需要修改多个元素；并且 DOM 保持简单，没有嵌套块。

3.我们的结论

我们相信，对于比较表中的每一行，都可以进行基准测试来衡量两个模型的性能。其他人在这里和这里做了类似的事情，比较了使用这两种模型的笔记管理器的性能。这些测试的问题在于很难对这两种模型的优劣得出准确的结论。Obsidian 在本地使用文档，因此您无需同步笔记。Roam Research 是一款非常新且优化不佳的应用程序。标准笔记在本地加密笔记。换句话说，事情并不总是同类的。

即使可以进行测试，我们相信答案甚至可能取决于每个用户如何使用该应用程序。假设用户 A 通常使用段落嵌套（折叠或展开它们）来组织长文档中的笔记。另一方面，用户 B 通常通过在文档中创建新文档来组织他的笔记。基于块模型的管理器可能更适合用户 A，而基于文档的管理器则更适合用户 B。

因此，我们试图尽可能地消除我们的怀疑，但我们仍然不确定答案，您认为这两种模型中的哪一种可以为我们的应用程序提供更好的性能，为什么？

4. 更新

我刚刚发现了一些非常有趣的信息。看起来，TinyMCE 和 CKEditor（最高版本 4）、视图和模型都与基于内容可编辑的 HTML 融合。然而，CKEditor 5 切换到 MVC [源 1]、[源 2]。

我在 TinyMCE 5、CKEditor 4 和 CKEditor 5 中做了一个简短的测试，粘贴了几 MB 的大剪贴板，后者有点慢。我希望很快能够对其他事情进行更多测试，例如拖动块或渲染大型文档。

在关于 CKEditor 5 在处理大型文档时的性能的 GitHub 帖子中，一位贡献者表示“它的运行速度显然比本机内容可编辑元素慢，但打字体验非常好”。

Answer 1

看来你已经做好功课了。数据库建模有时更像是一门艺术，而不是一门科学。我认为，对于这两种模型，如果优化得当，都可以获得良好的性能。因此，我建议您选择需要较少工作的一种。由于您已经研究块模型 8 个月了，这可能是您的最佳选择。