跳转到内容
Eidos Docs

数据视图

我最近意识到，几乎所有的生产力工具都在逼迫你做一个根本不应该存在的选择。

你在记笔记的时候，总会遇到这样的时刻：这条信息到底应该放在自由格式的文档里，还是结构化的表格里？这就像是被问：“你想要灵活性还是想要组织性？” 但这个问题本身就是错误的。为什么我不能两个都要？

想想现实世界中的图书管理员。他们不会告诉你：“对不起，这本书要么放在小说区，要么放在历史区，不能同时被归类到两个地方。” 图书馆有复杂的分类系统，同一本书可以通过多种方式被找到。但数字工具却还停留在”一个东西只能放在一个地方”的思维里。

这就是为什么 Notion 让人感觉别扭的原因。它给了你文档和数据库，但它们就像是两个不会说话的邻居。Obsidian 稍微好一些，它把所有东西都存成 markdown 文件，还有 dataview 插件来查询数据。但 markdown 的限制太多了，就像试图用推特的字符限制来写学术论文。

我见过太多人在这个问题上浪费时间。他们会花几个小时纠结一条信息应该放在哪里，或者更糟糕的是，他们会在不同的地方重复录入同样的信息。这不是生产力，这是在和工具较劲。

为什么传统方法不行

Section titled “为什么传统方法不行”

让我给你讲个真实的故事。我有个朋友，是个极其有条理的人，他保存有趣链接的方式让我印象深刻——不是因为有多好，而是因为有多混乱。

他的书签到处都是：

  • 有时候看到好文章，直接粘贴到当天的日记里，加个一句话评论
  • 有时候正儿八经地整理到”阅读清单”表格里
  • 有时候在项目文档里提到有用的资源
  • 有时候用自动化工具直接保存到数据库里

每种方法在当时的语境下都说得通。在日记里记录是因为当时正在写日记；整理到表格是因为想要系统化管理；在文档里提及是因为和项目相关；自动化保存是因为懒得手动操作。

问题来了：三个月后他想找某个链接，得在四个不同的地方翻找。这就像把钥匙分别放在四个不同的抽屉里，然后每次找钥匙都要把所有抽屉翻一遍。

数据视图的突破

Section titled “数据视图的突破”

数据视图解决了这个根本问题。它不是要求你改变行为，而是让你的数据变得可以被查询。

这里的关键洞察是：在 Eidos 中，一切都存储在数据库里。你的文档不是文本文件，而是数据库表中的行。你的结构化数据存在于适当的表中。这意味着你可以写 SQL 查询来跨越所有内容。

回到我朋友的书签问题。有了数据视图，他不需要改变任何习惯。他可以创建一个查询：

  • 搜索所有文档中的 URL
  • 从专用表中提取书签
  • 把所有内容合并到一个视图里
  • 显示保存时间和上下文

结果看起来是个表格，但实际上是多个数据源的实时视图。当他在系统任何地方添加新书签时，都会自动出现在这个视图中。就像有个隐形的助手在帮他整理，但从不打扰他的工作流程。

实际应用：找出所有待办事项

Section titled “实际应用：找出所有待办事项”

让我们看个具体例子。假设你想找到系统中所有的待办事项。传统方法是什么？打开每个文档，一个个检查。或者强迫自己只在一个专门的”待办事项”表格里记录任务。

但现实是，待办事项会出现在任何地方：会议记录里的行动项目，阅读笔记里想到的想法，项目文档里的检查清单。强迫自己只在一个地方记录任务，就像强迫自己只在卧室里思考——不现实，也没必要。

有了数据视图，你可以这样查询：

WITH
  valid_docs AS (
    SELECT
      id,
      content,
      created_at
    FROM
      eidos__docs
    WHERE
      json_valid(content) = 1
  )
SELECT
  json_extract(j.value, '$.children[0].text') as title,
  json_extract(j.value, '$.checked') as checked,
  d.created_at as created_at,
FROM
  valid_docs d,
  json_tree(d.content, '$.root.children') AS parent,
  json_tree(parent.value, '$.children') AS j
WHERE
  parent.type = 'object'
  AND json_extract(parent.value, '$.type') = 'list'
  AND json_extract(parent.value, '$.listType') = 'check'
  AND j.type = 'object'
  AND json_extract(j.value, '$.type') = 'listitem'

这个查询会找到所有文档中的待办事项。你得到一个叫 vw_<node_id> 的视图，包含系统中所有的待办事项，不管它们原本在哪个文档里。

更进一步：聚合不同类型的数据

Section titled “更进一步：聚合不同类型的数据”

现在假设你还有个专门的项目任务表格，用来追踪 bug：

titledescriptiondoneprioritycreated_atupdated_at
修复登录问题修复登录问题1高2025-01-012025-01-01
修复注册问题修复注册问题0中2025-01-012025-01-01

你可以把文档中的待办事项和这个表格合并：

SELECT title, done as checked, created_at FROM tb_<node_id>
UNION ALL
SELECT * FROM vw_<node_id>

现在你有了一个包含所有待办事项的统一视图——既包括散落在各个文档中的临时任务，也包括正式表格中的项目任务。

想查看最近一周的待办事项？基于已有视图再建一个：

SELECT * FROM vw_<node_id> WHERE created_at >= date('now', '-7 days')

这为什么重要

Section titled “这为什么重要”

数据视图改变了你和信息的关系。你不再需要在记录信息时就决定它的最终归宿。你可以按照最自然的方式记录，然后通过查询来组织和重新组织。

这就像是从”预分类”转向”后分类”。传统工具要求你预先知道信息应该放在哪里，但现实中，我们往往要等到需要信息时才知道最有用的组织方式是什么。

数据视图让你根据每个具体问题，以最有意义的方式来组织数据。不是预先强制将所有内容放入严格的类别，而是根据你试图回答的特定问题来动态组织信息。

这是一个更符合人类思维的方法。我们不是按照严格的分类来思考，而是根据当前的需要来连接和重新连接信息。数据视图让工具适应我们的思维方式，而不是强迫我们适应工具的限制。

技术上，数据视图是由 SQL 查询驱动的只读表格。你写查询，Eidos 用常规表格的所有功能来呈现结果——排序、过滤、不同的视图类型、自定义显示选项。但真正的价值在于跨数据源的聚合能力。

这不只是个技术特性，这是思考信息组织的全新方式。