Moy
1
Obsidian Bases 和多维表格一样吗？
基础定义
先给出定义——我理解的「多维表格」大致上是：
- 从特定的范围中，提取需要的数据，汇总显示在一个基础视图中。
- 这个视图通常是表格的形式，根据需要也可以切换不同的视图（例如日历、看板、图表等）
- 多个视图可以共享相同的数据源
- 可以查看和编辑笔记的属性，可自定义多种不同的属性类型
- 支持「筛选、排序、分组」功能
以上是基础定义，即「共性」。
差异部分
而说到 Bases 和传统多维表格（或 Notion 的“数据库”）的差异部分，大致是「数据来源」的区别。
- Obsidian Bases 默认数据源是全库笔记，需要通过筛选条件加以限定。
- Notion 数据源是给定的一个数据库，默认是空的，需要逐个添加新条目。
相当于一个是从 100 开始减法，另一个是从 0 开始做加法。
存储形式
而这些数据的「存储形式」，本质区别不大。
比如 Notion 是存在 PostgrfeSQL 中，思源我猜是存在 json 里的，Obsidian 显而易见是存在 md 文件里的。
很多人会觉得「一条数据就是一个文件，太麻烦了」，但其实只要看开一点，一堆只有元数据用来储存属性的「bases 数据文件」其实也不是啥问题。
[!info]
事实上如果你把一个 Notion 数据库导出到本地，你会发现它也是给每一条数据都生成对应的 md 文档，并将属性写入 md 的 yaml 元数据中。
无非是 Obsidian 直接将数据源头的 md 文档暴露出来，而 Notion 等软件会藏在用户看不到的地方，所以感觉差异明显。
但比起「数据存在哪儿」，两者的初始数据和限定范围的差异还要更大一些。
结论
总而言之——我的看法是，Obsidian Bases、Notion 数据库，还有多维表格，基本上是同一个东西。
大多数情况下它们能做到类似的事情。
（当然，Bases 目前还比较初期，很多需求需要借助插件来实现；而且对于过于复杂的功能——比如 Notion 那边的“Relationship”，尚且力有不逮）
题外话
Obsidian Bases 目前在中文版中的「数据库」翻译是我提交的：
当时也在纠结要不要叫做「多维表格」，但考虑到目前这个名词还基本局限在飞书，不算特别广泛；而和 Notion Database 一致的「数据库」比较容易让用户联想和接受，所以最终还是采用了数据库作为译名。
1 个赞
确实，这个差异还是挺影响数据库的实用性的，老实说我个人不愿意用较多的 md 文件来污染自己的库，即更希望每一个文件都是充实有用的 (可能是比较传统的用法?)
所以确实希望能用到思源和 Notion 那种单纯的数据库，不过这样的话确实有数据存在哪里的问题……
ChenK
3
忽然联想到之前曾深度使用TANA，十分痴迷其 Supertag 体系的便捷，以及表格、列表等多种视图切换的流畅体验。后来因网络问题弃用，在导出为 Markdown 文件后，反而对其 “祛魅”， 原本结构化的大纲内容转为 MD 标题，标签与属性也变成了 frontmatter。恰逢 Obsidian 的 Bases 功能正式上线，我发现二者逻辑高度相似：TANA 只是将这些类 MD 结构存储在云端不可见，而 Obsidian 则是放在本地。结合 kepano 的使用思路，放弃传统文件夹管理方式后，我对 Obsidian 的使用方式纠结也少了很多
trentswd
(trentswd)
4
我是觉得文件做数据库很好，但是完全没有文件内数据库不好
一个是操作系统里面小文件多了效率会下降，可以说逻辑上一样，但是小文件真的不如在数据库里面效率高
另一个是有一些敏感信息我不想暴露在文件名里面，也不想单独列出来
所以我也用datacore数据库管理细碎的东西
大部分还是用bases
好像datacore也是楼主推荐给我的
Moy
5
这确实是大部分人（包括我）都会有的一个思想障碍，哈哈 
但是反过来说，哪怕只填写了「属性」，也是承载了信息量的文件嘛 √
Moy
6
是这样的，很多时候软件端只是做了障眼法，让用户变得无感，就能提升用户体验了 。
Moy
7
确实如此，所以我在一些情况下也是用 【DV脚本】在单篇笔记里实现类 Notion Database 的轻量数据库 这样的方案。
主要是觉得那种临时的小数据库没必要鼓捣太麻烦，写在一篇笔记里就够了。
另外你说的这个想法， Obsidian Components 插件在后续的更新中可能会支持，感兴趣可以期待一下。
注：这是一款类似进阶版 Bases 的收费 OB 插件
