MarkEditor 的设计之初，考虑的就是管理本地数据，依赖的设计文件夹、文档。
也不构建特别的数据库，以用来在文档、文件之间构建更多的关联；这当然会带来局限，比如无法快速地通过 Tag 搜索，也无法获得一张图片到底被哪些文章引用了等关系类型的结构。

但我们非常清楚，作为桌面端 App，它与 Web 端有最大不同的一点是: 桌面 App 可以获得更多的算力。是故，有些地方，可以通过计算能力的投入，以及做必要限定的前提下创造新的解决方案，比如 MarkEditor 的全文检索方案既是如此，仍然是无数据库的技术方案。

让我们坚持这样的设计，是考虑到作为人类，对于数据的理解无法做到机器一般，我们希望 MarkEditor 在代码层面识别的数据，应该跟人类识别到的数据是接近的。
因为这样，会有让人无法拒绝的好处。

方便管理、整理、同步

管理的是本地的文件夹，MarkEditor 对文件夹所处的位置不关心，只要它在本地的电脑上，MarkEditor 就能进行管理。
有些时候，在文档积累到一定程度时，(一个工作目录下)通常会进行整理、归档；而一个 App 其整理、归档的能力毕竟是有限的，而此时在 MarkEditor 中，使用者只需要在自己本地目录中进行操作就可以了(这非常高效的)，并不需要只在 MarkEditor 中操作。

MarkEditor 所管理的(工作)目录，可能是位于某个云盘(或者 FTP)上的，那么这个目录就拥有了数据同步的能力；如果在持续做 Time Machine 的，则数据除了 MarkEditor 默认提供的版本记录之外，也有了另外一层机制的历史记录保障。
如果需要备份一个 MarkEditor 管理的工作目录，只要直接将整个目录拷贝一份就可以了，不需要任何其它的备份工具。

还有其它优点吗？

方便管理、整理、同步 已经足以让我们坚持本地目录的数据结构了。
或许很多年以后，MarkEditor 没有保持足够的进化能力，而被其它的 App 取代了，我们希望 MarkEditor 的使用者，起码不用为数据的迁移而担心。