Eidos vs Obsidian

Obsidian 是一个伟大的产品。Eidos 的很多设计理念都深受 Obsidian 启发：本地优先、数据所有权、可扩展性、开放格式。Obsidian 证明了一个重要的观点：用户应该拥有自己的数据，而不是把它们托管给某个可能明天就消失的云服务。

Obsidian 做对了一件事：它把知识管理建立在纯文本之上。文本是人类最持久的数据格式。当你的笔记存成 .md 文件时，你知道它们在二十年后依然可读。这种确定性是珍贵的。

但文本也有局限性。

假设你在做一个独立游戏。你有几百个角色，每个角色都有名字、等级、技能、装备。这些信息高度结构化。在 Obsidian 里，你得为每个角色创建一个 markdown 文件，把属性塞进 frontmatter。然后祈祷 Obsidian 的搜索和插件能帮你查询这些数据。

这就像用锤子拧螺丝。能拧，但不优雅。

结构化数据

Obsidian 团队也注意到了这个问题。他们最近推出了 Base 功能，试图为用户提供更好的结构化数据管理体验。这确实是个进步，但两者的实现方式有着本质差异：

在 Obsidian 中，数据库是建立在 markdown 文件之上的。每一行数据仍然对应一个 .md 文件，数据库只是这些文件的可视化表现。当你在 Obsidian 的表格中编辑一个单元格时，你实际上在修改某个 markdown 文件的 frontmatter。

在 Eidos 中，数据库就是数据库。当你创建一个表格时，你得到的是一个真实的 SQLite 表。数据直接存储在数据库中，没有中间层。

这不只是实现细节的差异。这是哲学上的分歧。

Eidos 做了一个简单的选择：结构化数据用数据库，非结构化内容用文档。不是因为我们不喜欢 markdown。恰恰相反，我们太喜欢了，所以不想滥用它。

想想 Excel 和 Word。没人会用 Word 来管理一张包含 1000 行数据的财务报表，也没人会用 Excel 来写一篇长文章。这不是技术限制，而是工具的天性。

当你有一张包含 1000 行数据的表格时，SQLite 知道怎么处理。它为此而生。让 markdown 承担这个责任，就像让诗人去做会计。

这种架构差异带来实际的后果：

性能：当你有 10,000 行数据时，SQLite 的查询速度比解析 10,000 个 markdown 文件快几个数量级。 Eidos 甚至能处理百万级数据。
完整性：真正的数据库有约束、事务、ACID 特性。Obsidian 的 base 只是界面层的魔法
灵活性：你可以用 SQL 查询 Eidos 的数据，可以写复杂的连接查询，可以做聚合统计。Obsidian 的查询能力受限于它的插件系统。

这不是贬低 Obsidian 的 base 功能。对于轻量级的结构化数据，它很有用。但当你需要真正的数据库功能时，Eidos 是更好的选择。

Obsidian 是以 markdown 为核心的知识管理工具。Eidos 是以数据库为核心的数据管理工具。在结构化数据管理上，Eidos 更具优势。Eidos 专注于数据管理而不是知识管理。