实际用起来就是每个点都开个文件, 感觉有点压力.
我的笔记是记在一个org文件中的，挺期待这个功能的。
这个就讲究知识体系的内化,而非知识收藏(简单的复制粘贴下载),配合搜索功能
如果roam可以像org-brain一样，支持以heading而非file作为基本的笔记单位就好了，不过这个功能已经被推迟好几次了 Show back-link to current headline (not current file) · Issue #801 · org-roam/org-roam
个人同样也非常期待此功能，觉得org大纲+块引用才是笔记系统最优方案。 层次清晰，方便回顾，还省下了整理标签的功夫。
2 个赞
是的，卡片盒笔记法的实现方式大多是一个笔记一个文件，我觉得原因一说是沿袭自卢曼「一个笔记-一个卡片-一个文件」，但是卢曼用一个卡片主要是为了方便唯一编号，进而构建联系。然而如今，笔记载体在从物理实体的卡片升级到数字笔记的过程，我们有更多的方法唯一表示笔记，执着于文件已不再必要，甚至heading的ID是比文件名更为可靠的标识方法。
因此，现在大部分是基于文件实现还是从逻辑复杂度出发的吧。毕竟文件与笔记的逻辑对应关系很明确。而对于heading而言，可能是通常意义的笔记，也可能是笔记中的大纲标题，我没有仔细考虑过，如果等同对待是否会有问题。brain也是先支持的文件笔记，再支持的heading笔记。
采用文件组织的另一弊端是把知识管理和日程管理再次割裂。因为multiple small files对于agenda而言简直是灾难。而知识管理+项目管理的无缝结合本来是org-mode的优势。
我觉得卡片盒笔记不是说反对大纲层级，而是说除了大纲层级之外多考虑其他的联系方式：引用与被引用，笔记的周围视觉，关键词等。如果是像某些人说的，用卡片盒笔记法主要原因是不用考虑笔记放在哪里。那其实把所有笔记作为heading放在一个org文件也是一样的。
目前基于org-brain加了Backlink的展示，还很粗略，只是简单满足个人当前需求。
关于笔记实践方法的更多讨论参见 对比 org-roam 和 org-brain - #19，来自 yuchen-lea
4 个赞
我是赞同多而小文件形式,目前个人的理解是:
使用多文件的形式,是有利于记录无序的思维和单次有限的知识吸收,避免多次整理(相对于大纲的层次性).
至于相关主题的编写,利用backlink和tag进行联系和过滤.
能有块引用功能是更好的,有利于联系以前的文件.
为什么这么说呢？agenda的初衷不就是将分散在不同文件的日程收集起来统一展示嘛。
我个人也是比较倾向多文件形式，org-mode在处理多文件方面是有挺大优势的。而且多文件也能配合headline，再加上org-roam已经支持对headline的引用了，两者综合起来的效果挺不错的。
曾经在哪里看过，建议把roam的目录和agenda分开，Roam 的开发者说：
The reasons why Org-roam works better with small files is that exact opposite of why Org-agenda works better with big files.
出处：
不知你说的多文件的多是多少数量级呢？我也不是只用一个大文件，目前一共有近50个文件，最大的将近2M；但是有数万个headings。如果只考虑知识卡片的话，也得有几千个吧。按照roam的方法，每个笔记一个文件，要加数千个小文件到agenda list，我会很担心emacs performance。（不少人有类似的担忧：Combining normal org-files and org-roam : orgmode）
在我的理解中，agenda处理的基本单位是headline，比如说我有一个关于「org-roam」的大纲，标记了周期性计划以便跟进开发进度。如果现在这个大纲变成了一个文件，我不太清楚文件是否能展示在agenda中。或者我需要在这个文件中再新建一个名为「跟进org-roam开发进度」的headline？
严格来讲，不是多文件的形式，而是无层次的组织结构，有利于记录无序的思维和单次有限的知识吸收。在一个目录中的许多无层次的文件和在一个文件的许多无层次的大纲，本质都是无层次的组织结构。这就是为什么我说「把所有笔记作为heading放在一个org文件也是一样的」。
因此，个人之见，多而小文件和 少而大文件 在知识管理角度来看没有本质区别。关键是目前功能的实现是应用在什么对象。比如说，以我所知，列视图只能用于大纲，无法用于文件。roam的backlink是应用于文件（诚如 @VagrantJoker 所说，roam支持了标题的引用，但是它会在该文件的标题2的反向链接中，展示链接到该文件标题1的条目，因此很明显，基本单位是文件，具体实例）
我也很推荐在大纲之外，建立笔记之间更多的关联。毕竟联想是理解掌握、乃至迁移运用的关键。从无到有当然是进步，但是随着笔记数量的增长，新的问题会出现：
（来自我坛某友，欢迎告知来源）
因为backlink只是反映了「引用」这一种关系，笔记之间的关系是很多的：影响、相反、相似等等（更多讨论参见此处），因此在backlink和tag的联系之上，我觉得还需要额外的结构，说明具体是怎样的关系（fine-grained labeled associations）。
目前这种实现方式基于ID，所以从粒度来讲，依然是大纲，没有变得更细。所以想知道与直接的ID链接到大纲相比，它扩展了哪些应用场景？
1 个赞
我目前的笔记数量只有近千个，和u/ftrx提到的一样，在我的机器上第一次打开agenda的时候有点慢，后续操作无明显卡顿，考虑到我重启emacs的频率不高，我认为这是可以接受的。
不需要，将org-roam-title-sources设置为'headline后与平常org操作相同。
关于性能,主要还是在于org的解析, 多而小文件和少而大文件在同样内容的情况下应该差距不大,推荐配置
(setq org-roam-db-gc-threhold most-positive-fixnum)
这个问题我觉得是无法避免的,目前可以通过Exclude和Buffer Network来过滤
就知识内容而言,没太多差别,但独立文件可以赋予更多独立的属性,如tag,至于应用场景,我目前主要用于过滤.
感谢提供这些有用信息！有两点尚有疑问：
无法避免个人觉得有些绝对，只不过目前难以通过技术手段解决，更多依靠手动组织信息结构吧。这就需要权衡投入的精力和未来的收益了。
property、tag这些不都是headline具有的？而且headline的tag还能进行mutually exclusive等高级设置。
对我个人而言，目前的阻力过强（要把成千上万的headline迁移成roam支持的形式）而吸引力不足（唯一无法实现的是展示二度以上关联的笔记，不过目前对此也没有强需求）……
感谢补充。看了下描述，似乎是定义如何得到roam note标题的方式？也就是说， 将 org-roam-title-sources 设置为 'headline ，roam笔记文件中的第一个headline会作为标题。感觉roam自己又定义了一套title、tag、key
1 个赞
hi 你这个backlinks是用什么包实现的
我也在用obsidian, 挺容易上手的. 不过我的用法很初级就是了:)
参考org-roam简单写的function，加到org-brain里显示，相当初级
正考虑从Obsidian转移到org-roam，原因是Obsidian在笔记达到一定数量时会变得很卡，曾经导入一个约100000+的词库，非常卡顿。不知道Emacs对大数量文件的支持如何。
我这边有 81536 个节点，找节点 10 秒左右的时间，机器不是很新，也没有用固态硬盘。下图是使用感受，个人感觉 Emacs 是能胜任的。
1 个赞
其实笔记达到一定数量会卡的问题，并不难解决。只需要根据一定的规则，分库、分表存储数据。这样就可以解决检索效率低的问题。
1 个赞