- 每次大本版更新，都是提心吊胆，因为新特性总是在负面影响甚至破坏已有的工作流
- 1.2.5 最大的改动便是文件名 ID 化，这直接导致
- 除思源外任何工具对思源文件的管理不具备可读性和可操作性性
- 系统资源管理器几乎变为资源管理空气
- 文件级，文件夹级拷贝分享变的异常艰难，以至不可能
- 第三方同步盘的同步日志变得没有丝毫可读性，同样文件级的版本恢复变得异常艰难（特别是思源自身的同步仍然只能作为 plan B, 即便一直改进，应该也无法和专业软件（坚果云）比肩）
- 对系统工具，对第三方工具的友好性，不正是本地化的一大便利么（另一大便利是安全）
- 如果 ID 化是子文档的代价的话，那真是子文档的一个最糟糕的本地化实现，更何况子文档也丝毫不会对笔记带来本质的提升。纯在线的 ID 化无所谓，用户根本不关心这个。可用思源就是冲着本地来的
- 特性的引入伴随思源一直在收紧自由度，从资源的统一管理到文档名的 ID 化，收紧的方向正常，但方法真是一言难尽
- “思源用户不关心本地文件名，软件能打开就行”，但还是有一部分用户关心文件名的，越是深度用户越关心，随着笔记的数量提升，协作需求的提升，也许会有越来越多的用户看到这一串 ID 而苦恼吧
- 实现同样的功能，应该有比文件名 ID 化更高效，更平和的实现吧？希望两位主创能考虑下这个问题
-
思源笔记问题反馈
1472 引用 • 4228 回帖 • 16 关注
广告 我要投放
相关帖子
优质回帖
-
88250 • • 3 • 9 赞同订阅者
你好，是时候和大家分享一些这方面我们的设计考虑了。
从使用角度
思源不是文本编辑器，而是知识管理系统。如果以编辑器的方式来使用，肯定会感到别扭的。
- 同一层级下需要支持同名文档，这样能将新建、重命名、移动等操作的同名阻断问题降低，使用起来更流畅
- 子文档形式比文件夹形式效率更高，能够充分利用文档树的空间，从概念上也统一为文档，减少不必要的实体
- 分享和协作不是思源现阶段的目标，现在就这样用的话是肯定不会好用的，协作大概在 v3 阶段会开始设计
从技术实现角度
优先考虑稳定性。
- 通过文件实现易变数据的互操作性是一个糟糕和错误的方向，因为多个进程各自直接读写易变文件有概率会导致数据损坏。概括一点讲就是试图通过共享文件、共享内存来实现互操作性的方案都存在一致性问题，正确的方案是通过 API 进行交互，各进程内自己保证一致性
- 使用人类可读的文本在跨系统平台时存在大小写问题，比如 Linux 上允许同时存在
SiYuan和siyuan文件，但是 Windows 上则不允许，该情况一旦发生数据就可能会被损坏
寻求平衡
我们一直在寻求对普通用户和对社区开发者都友好的平衡点。
- 对普通用户尽量屏蔽底层细节，所以思源迟早要覆盖一些在文件系统上的常规操作，比如批量移动、删除文档，最终目标是用户不必关心文件结构，专注于使用
- 对开发者而言，需要的是稳定的方案，如果某个方案可能存在某个问题，那么这个问题一定会在将来的某个时候发生
忒修斯之船
思源这样一直更新下去，还是当初的思源吗？
在发布 v1.2.0 的时候我们说过，如果没有更好的替代方案，不会轻易删除已有特性，这次变更我们觉得并没有违背这个承诺。
一个产品如果没有明确的产品方向和架构思路，这个产品就算做到能用也不会是个好产品。至于个性鲜明或者说思路清奇的产品能否被用户接受，这只能用市场来检验了。好产品无需推广，烂产品就算被骂死也不会有所改变。
最后，我们作为主创团队，直接劝退用户的话不太礼貌，然后还会有人说：“你看他们，傲慢得不得了，容不得半点意见”。但这样的评价并不重要，重要的是我们觉得浪费了大家的时间精力，与其忍着用，不如早点换。
以上。
-
programfan • • 2 • 3 赞同
说几点看法和期望：
- 如果关心修改历史，但又只关心文件名，这个只能说是“叶公好龙”。我不用思源的历史功能，也不用第三方同步的历史功能，自己建了一个 git 仓库，手工管理历史，清清楚楚。只要思源维持“本地 + 文本”这种技术路线，想要修改历史有无数种办法，为什么要纠结文件名？
- 如果确实对 id 和文件名的对应关系有需求，在 sy 文件里面有，随便找个 json 解析工具一提取就搞定了，只是稍微费一点功夫而已。
- 我们作为软件的用户，要区分软件的「内部实现」和「外部接口」的边界。简单地说，思源如何组织笔记文件、如何存储笔记数据，这个是软件的内部实现，本来就是会随软件发展不断变化的。但思源将笔记「按目录和文本文件组织为本地磁盘的数据」，这是软件给用户和开发者的保证，可以预期是不会急剧变化的，可以理解为是一种外部接口。我们搭建自己的工作流，要基于软件的「外部接口」而非「内部实现」。如果真要基于「内部实现」，就要做好持续跟随改变的准备，而不是不断给软件开发者提要求说「内部实现」变化不合理。
- 期望思源笔记尽快梳理出一个稳定的开发接口，包括数据格式、数据存储、查询修改等，在能给出稳定预期的地方，尽量给出稳定预期，这样大家知道什么会变，什么不变，搭建工作流和开发额外工具也就比较放心。
-
audiolabj • • 2 • 2 赞同
深以为然！
- 文件名的纠结，我们实践里的理解是：习惯于一段内容在一个可见的文件里，然后以文件名看更新，以文件或文件夹移动或复制内容，习惯这样的话，文件名不用改成 ID，随便改动一些都会不好找；如果是以内容块来组织的话，移动，查找和复制都是块的内容（包括块的嵌套），习惯了这样，焦点就在内容里，而且是每个组织好的要点里（在 RemNote 里是一个 Rem)，这对于知识的组织管理而言，是更顺畅的。文档名，只是应用内一个大容器块的标签管理，，如果需要文件级的交换，用导出 md 后的 pandoc 类的方法，转成 ppt 也行。
- 修改历史管理，我们也是用 git 来做的，而且是团队协作，十几个成员，从需求到设计到开发代码到测试，直到交付和销售支持材料，甚至开发者自己的学习笔记，都用思源做源头内容管理，3 个月时间我们用思源已经发布了两个产品都在 B 端客户进入部署阶段。git 管理协同，相对于飞书和语雀的在线历史管理，优势不仅在于可以管理到每个 commit 的每个要点，而且在于文档的发布范围，可以多分支管理，小组的 feature 开发的需求文档，和主版本分离，没啥问题。
- 思源的 json 格式，是我们团队选择思源并且每人购买会员的理由，不仅 ID 和标签的对应可以管理，而且节点间的关系，完全可以还原；如果改了数据库作为主存，反倒会引起我们很大担心，且不说如何用范式化 schema 适应 nosql 的定义场景，字段映射的管理，元数据和实际内容的对应查看，引用完整性的潜在风险这些坑，光是实时分享版本改动引起的数据字段结构和值域定义更新问题，就成了一个麻烦。
- 还是那句话，思源笔记作为知识管理工具，而不是编辑排版工具的方向，非常认同；知识图谱的 schema，就是图；比起范式化的二维表，protege 这类知识定义 rdf 工具，是和 json 这种格式具有好得多的亲和力的，而且思源支持的 graphviz，可以直接和 protege 进行转换。
- 同样，也是期望思源尽快梳理出稳定的开发接口，sql 查询的数据库元数据和字典文档开放程度能更好一些，便于跟进；如果有一天，思源把主存储改为封闭数据库，不再坚持“本地 + 文本格式”，也希望及时告知，恕不能够继续一路升级同行了。
- 思源用户圈子建立很难得，大家场景不同，需求各异，求同存异不容易，一方面让开发者协调取舍，一方面多交流，理解，分享一些不改版本条件下解决问题的方法吧。
请输入回帖内容
...
-
WeiCJ • • 1 赞同订阅者
我想你应该只是想要能直接看到 md 文件，从而在必要的时候可以直接分享 md 文件，😂 我感觉这个与子文档并不冲突。我看了思源笔记在之前的版本也是用 md 文件存储，然后启动的时候转为数据库，以便于检索；后面版本改为 sy 的 json 文件，依旧是数据库检索；现在是改了文件的展示形式，但依旧是数据库检索。
综上所述，目前只是文件的展示形式变了，造成部分人的观感下降了 😋 那软件可以在数据根目录建一个 md 文件夹，里面存放自动生成的 md 文件即可。（其实也就相当于自动导出功能，这样也许可以平衡不同使用习惯的人）
1 回复 -
boboxing •支持者 订阅者 作者
文件名保留，数据库该怎样就怎样，这不是最佳实现吗？是 json 或 md 无所谓，仅仅只文件名的可读性而已。轻度用户可能体会不到重度用户此时的痛苦。重度用户本来数量也不多。😂
-
Achuan-2 • • 1 赞同订阅者
首先还是能定位文件的，所以你前面将资源管理器变成管理空气略显夸张。定位之后，如果需要分享，照样可以复制分享。或者直接导出 md 文件分享。
其次也打开 sy 文件也可以确定下文件名的
文件存储 ID 化应该不仅仅为了子文档才这样做的，因为用中文名照样可以实现。
具体为何要 ID 化，我不好乱说，还是等官方来解释吧。
如果 ID 化能更好保护隐私、能让思源的功能实现更加稳定，那我愿意支持 ID 化。
并且这种 ID 化，于我来说，在分享层面应该不会有特别大的影响，依旧是通过思源定位文件位置，然后分享，如果愿意接受、习惯这些 id，应该不会对分享造成太大的麻烦才对。
反而我觉得是管理文档层面不大方便，例如我需要将几个文档移到另外一个笔记本下，可能就需要反复查看 id，移动的时候因为思源会锁文件又需要关闭思源，就会非常麻烦。不过这点等官方支持跨笔记本移动文档，和批量拖动移动文档后会得到解决
3 回复1 操作Achuan-2 在 2021-08-22 10:58:38 更新了该回帖 -
-
boboxing • • 5 评论支持者 订阅者 作者
恰恰也是分享层面，现在一看同步列表（坚果云提供），别人分享我的都变成了一串 ID，完全不知道分享的啥。当然分享时我是把思源当 word 用了，而且用的很舒服。试想，现在互相分享，别人传给你的是一串 ID，发给别人的也是一串 ID，这不是观感的问题，是工作效率问题了。这里的分享不是到处分享，而是源文件分享，坚果可以方便的设置读和写的权限，所以分享根本不用导出。直接分就完了，还能利用那些精美的主题。现在导出都是没有主题的。
-
-
-
-
leiyuy •
用 1.2.31 的时候，我个人感觉思源笔记的存储方式和 calibre 的管理思路是一样的，不仅能在线管理，还能在本地管理。calibre 是文件 + 数据库存贮。
这个管理思路我是比较喜欢的。
既能数据库化存储，为将来构建知识图谱奠定基础，同样也能够兼顾得到本地资源管理器，为实际的文件管理无缝融合。
-
-
-
-
Hildaquan •订阅者
我自己有近千个文档，我有时引用的时候也会偶尔发现有重名的。当自己的笔记数非常多的时候，重名是不可避免的。
一般我发现重名后，要么合并文档，要么根据内容异同改名
1 回复 -
-
-
-
88250 • • 3 • 9 赞同 • 2 评论订阅者
你好，是时候和大家分享一些这方面我们的设计考虑了。
从使用角度
思源不是文本编辑器，而是知识管理系统。如果以编辑器的方式来使用，肯定会感到别扭的。
- 同一层级下需要支持同名文档，这样能将新建、重命名、移动等操作的同名阻断问题降低，使用起来更流畅
- 子文档形式比文件夹形式效率更高，能够充分利用文档树的空间，从概念上也统一为文档，减少不必要的实体
- 分享和协作不是思源现阶段的目标，现在就这样用的话是肯定不会好用的，协作大概在 v3 阶段会开始设计
从技术实现角度
优先考虑稳定性。
- 通过文件实现易变数据的互操作性是一个糟糕和错误的方向，因为多个进程各自直接读写易变文件有概率会导致数据损坏。概括一点讲就是试图通过共享文件、共享内存来实现互操作性的方案都存在一致性问题，正确的方案是通过 API 进行交互，各进程内自己保证一致性
- 使用人类可读的文本在跨系统平台时存在大小写问题，比如 Linux 上允许同时存在
SiYuan和siyuan文件，但是 Windows 上则不允许，该情况一旦发生数据就可能会被损坏
寻求平衡
我们一直在寻求对普通用户和对社区开发者都友好的平衡点。
- 对普通用户尽量屏蔽底层细节，所以思源迟早要覆盖一些在文件系统上的常规操作，比如批量移动、删除文档，最终目标是用户不必关心文件结构，专注于使用
- 对开发者而言，需要的是稳定的方案，如果某个方案可能存在某个问题，那么这个问题一定会在将来的某个时候发生
忒修斯之船
思源这样一直更新下去，还是当初的思源吗？
在发布 v1.2.0 的时候我们说过，如果没有更好的替代方案，不会轻易删除已有特性，这次变更我们觉得并没有违背这个承诺。
一个产品如果没有明确的产品方向和架构思路，这个产品就算做到能用也不会是个好产品。至于个性鲜明或者说思路清奇的产品能否被用户接受，这只能用市场来检验了。好产品无需推广，烂产品就算被骂死也不会有所改变。
最后，我们作为主创团队，直接劝退用户的话不太礼貌，然后还会有人说：“你看他们，傲慢得不得了，容不得半点意见”。但这样的评价并不重要，重要的是我们觉得浪费了大家的时间精力，与其忍着用，不如早点换。
以上。
5 回复 -
-
boboxing •支持者 订阅者 作者
感谢主创耐心回复！
- ID 化的主因是“使用人类可读的文本在跨系统平台时存在大小写问题，比如 Linux 上允许同时存在
SiYuan和siyuan文件，但是 Windows 上则不允许，该情况一旦发生数据就可能会被损坏”，我一直以为是子文档的原因。但 ID 化不是“更好的替代方案" - 子文档是个好特性
- 关于软件的一切，主创拥有唯一最终解释权
- ID 化的主因是“使用人类可读的文本在跨系统平台时存在大小写问题，比如 Linux 上允许同时存在
-
-
xuanlemming • • 1 赞同支持者 订阅者
支持并理解 D 大的部分想法，但并不完全认同，子文档是挺精致的，也好看，但是没有配套的措施出来前，无法凸显出它的好处(如何更好的利用好原来的文件夹)。
当然，因为每个人的工作流不同，所以肯定会误伤部分用户，所以其实重大更新前可以来个预告。
支持知识主帖作者认为的思源逐渐丧失了本地资源管理的功能的观点，因为在某个版本把 asset 文件统一合并的时候，我就体会到了，包括现在，打开本地文件夹，打开的全是一堆 id 化的文件，很难轻易区分哪个是哪个了。
那这样会不会有大的影响呢？个人认为，要想用户接受，思源需要做到的是，不断提升稳定性和对附件管理的更友好地支持，以及便利好用的导出功能。这样我不管理文件夹其实无所谓。那么，似乎 1.2 后，思源的确不太有丢图片的情况了(这也是我当初不支持 asset 文件统一的原因，因为丢图了在当前文件夹，我还能找到并补救)
另外，附件，我觉得目前而言，思源的附件管理并不很方便，可能我倾向的是为知笔记那种管理方式。
最后，导出的话，应该也是一致需要努力的方向，因为很多问题容易反复。
总之，希望思源越来越好，也希望大家保持沟通，不要轻易离开或指责，大家一起为更好的知识管理而努力！
-
wfan14513 •捐赠者 支持者 订阅者
我觉得新版挺好用。思源可以批量导出 md 文档，根本不影响分享啊，从资源管理器按文件夹分享才麻烦，伴随的图片附件挑选起来多麻烦啊。
其实，现在对一些人来说就缺了个笔记本之间的移动文档功能，否则应该不需要资源管理器了，这个功能估计很快会有。
-
larryggao • • 1 赞同支持者 订阅者
- 其实比较认同作者的观点的，每次大版本更新，我也是提心吊胆。最近几次的版本的改动还是挺大的，1.2.5 我第一次迁移就直接把数据丢失了，幸好有备份，通过回到老版本还原数据再重新安装才搞定。之前还在工作群里推荐过思源，后来主动说明思源的不稳定性问题，避免别人上车结果把人坑了。不是忠实粉丝，是经不起这样折腾的。
- 文件名 ID 的最大问题，除了资源管理器外，第三方同步盘的同步日志就直接无法看了。我平时公司和家两台电脑，每天都需要使用到同步功能，原先就打开同步盘看下最新同步的文件名，现在基本上实现不了这点了。思源的同步功能尝试过，中间爆出来好多次连不到服务器，直接弃用了。
- 关于子文档，到底有啥好处？什么场景下有用？这方面在更新说明中完全没有体现，说实在话，我现在都不知道子文档的用处是啥？有大佬能指导一下嘛。
1 回复 -
crowds21 •订阅者
我个人看法,双链笔记最利好的是科研人员,许多 RR 也好 Logseq 也好,哪些最终度使用的似乎都是科研人员. 普通人比起记录旁的信息来说,生活场景中大多是,需要更多的实践(搬砖).
之前其他用户解释,大概意思就是: 子文档主要就是让文档树更多的集中有用的信息. 因为文件夹只是一个区分的作用,本身没有什么其他作用.变成子文档之后,文档书内都是文件,大概意思就是没有多余的东西了,同时文档之间的逻辑性更强了.
1 回复 -
fangly • • 1 赞同订阅者
我认为，目前文档名 id 化带来的唯一负面影响就是在坚果云中看不到是什么文件修改了（至于无法在资源管理器中管理文件，等到 d 大把思源内部的文件树功能优化好，资源管理器就完全用不到了，文件树完全可以替代资源管理器。至于想要把思源源文件分享给别人，肯定是在思源内部查看，编辑好，然后文件树中打开-打开文件位置，不可能有人从 C 盘根目录一步一步打开文件夹找文件吧，显然是思源内部定位后再定位源文件更快）
因此，用户真实的需求是能查看到文件修改的历史记录，用户默认的查看方法是通过坚果云查看，现在通过坚果云查看不了了，用户就觉得 id 化这个决定是不好的。
所以用户抱怨的根本不是文档名 id 化，而是无法查看文件修改的历史记录
然而事实上，要查看文件修改的历史记录最好的方法是通过坚果云吗？这种依赖第三方软件的方法肯定是无法作为最佳解决方案的。我认为更好的解决方案是 d 大开发查看文件历史修改记录的功能。
因此大家不应该反对文档 id 化，这是没有意义的，而应该让 d 大开发查看文件历史修改记录的功能。
1 引用1 操作fangly 在 2021-08-22 18:56:11 更新了该回帖 -
fgdl30458df • • 1 评论
不觉得文件 ID 化有什么好处和"文件重名"有什么优势和值得的需求
要说好处的话也只是对于开发者而言的吧,但对于用户体验来讲确实被大砍了一刀.
正如上方反馈,面对全是 Id 数字的文件确实让很多"深度使用"需求的场景变得非常不方便,甚至变得无法实现.
这等于思源将自己"长处"主动变成了短处.
当然作为开发者可以无视这些反馈,因为些意见都是思源问题的存在.
对于普通用户来讲一款笔记软件的消费粘性其实对他们没有那么大,面对"如雨春笋"的笔记软件的出现他们有很多的选择,
但对于"深度用户"来讲为了实现"特殊"需求的使用场景,他们往往不惜进行消费,而这些用户群体才是思源应该把握住的,这样用户群体也是思源能够继续走下去的动力.
所以将文件 ID 化我觉得开发者应该要更加的慎重考虑了,毕竟一款笔记的成功不应该只看功能自身,而是看和其他平台的"互动兼容性"强不强,
毕竟没有什么笔记软件是完美的存在,和其他软件的互动性可以保证自身的缺陷,在一定程度上得到弥补,或者干脆将第三方变成自身通往成功的"轮子".
1 回复同感 + 同意， 为了实现某些特性，缓解某些问题，文件名 ID 化应该是最容易实现的方案，编程的易实现性放在了用户体验之上。 -
programfan • • 2 • 3 赞同订阅者
说几点看法和期望：
- 如果关心修改历史，但又只关心文件名，这个只能说是“叶公好龙”。我不用思源的历史功能，也不用第三方同步的历史功能，自己建了一个 git 仓库，手工管理历史，清清楚楚。只要思源维持“本地 + 文本”这种技术路线，想要修改历史有无数种办法，为什么要纠结文件名？
- 如果确实对 id 和文件名的对应关系有需求，在 sy 文件里面有，随便找个 json 解析工具一提取就搞定了，只是稍微费一点功夫而已。
- 我们作为软件的用户，要区分软件的「内部实现」和「外部接口」的边界。简单地说，思源如何组织笔记文件、如何存储笔记数据，这个是软件的内部实现，本来就是会随软件发展不断变化的。但思源将笔记「按目录和文本文件组织为本地磁盘的数据」，这是软件给用户和开发者的保证，可以预期是不会急剧变化的，可以理解为是一种外部接口。我们搭建自己的工作流，要基于软件的「外部接口」而非「内部实现」。如果真要基于「内部实现」，就要做好持续跟随改变的准备，而不是不断给软件开发者提要求说「内部实现」变化不合理。
- 期望思源笔记尽快梳理出一个稳定的开发接口，包括数据格式、数据存储、查询修改等，在能给出稳定预期的地方，尽量给出稳定预期，这样大家知道什么会变，什么不变，搭建工作流和开发额外工具也就比较放心。
2 回复 -
boboxing •支持者 订阅者 作者
- 作为发帖人，本人只是深度笔记用户，不是程序员兼职笔记用户
- 外部接口，内部实现的范式感觉也基本适用于 VSCode 了，VSCode 用 ID 存文件，程序员们是否欣然接受，毕竟可以重命名了。
-
fangly • • 1 赞同订阅者
正如上方反馈,面对全是 Id 数字的文件确实让很多"深度使用"需求的场景变得非常不方便,甚至变得无法实现.
举个例子？我真没看出来哪个功能在文档名 id 化后无法实现
有什么功能需求就说需求，别把所有问题都怪到文档名 id 化上
1 回复 -
我们是用户不是开发者 OK? 是体验使用和消费者.
不方便这一点就足够说明问题了,
我们只需要反馈,和等待最终的结果,来决定是否继续支持这款笔记软件
至于我说的"无法实现",你非要将问题隐隐提上到技术层面来讲,那么还真是有非常多方法可以"实现"的
但是有必要吗? 作为用户我只需要"使用"和消费,难道我需要自己写个工具吗?
至于提出需求, 我们是可以提出需求,但最终实现是未知的,可能并不是自己想要的,也可能被忽略,这都是有可能的
1 回复1 操作fgdl30458df 在 2021-08-22 20:42:08 更新了该回帖 -
fangly • • 1 赞同订阅者
我什么时候把问题隐隐提到技术上了？可能我的表述让你产生了误解，我就是从用户角度来说的。
除了坚果云看不了更新日志之外没有任何功能因为 id 化而受到实质影响，然而坚果云看更新日志这本身就不属于思源的功能。
你说思源哪个功能需求现在因为 id 化而不方便？
1 回复 -
-
-
-
-
audiolabj • • 2 • 2 赞同赞助者 订阅者
深以为然！
- 文件名的纠结，我们实践里的理解是：习惯于一段内容在一个可见的文件里，然后以文件名看更新，以文件或文件夹移动或复制内容，习惯这样的话，文件名不用改成 ID，随便改动一些都会不好找；如果是以内容块来组织的话，移动，查找和复制都是块的内容（包括块的嵌套），习惯了这样，焦点就在内容里，而且是每个组织好的要点里（在 RemNote 里是一个 Rem)，这对于知识的组织管理而言，是更顺畅的。文档名，只是应用内一个大容器块的标签管理，，如果需要文件级的交换，用导出 md 后的 pandoc 类的方法，转成 ppt 也行。
- 修改历史管理，我们也是用 git 来做的，而且是团队协作，十几个成员，从需求到设计到开发代码到测试，直到交付和销售支持材料，甚至开发者自己的学习笔记，都用思源做源头内容管理，3 个月时间我们用思源已经发布了两个产品都在 B 端客户进入部署阶段。git 管理协同，相对于飞书和语雀的在线历史管理，优势不仅在于可以管理到每个 commit 的每个要点，而且在于文档的发布范围，可以多分支管理，小组的 feature 开发的需求文档，和主版本分离，没啥问题。
- 思源的 json 格式，是我们团队选择思源并且每人购买会员的理由，不仅 ID 和标签的对应可以管理，而且节点间的关系，完全可以还原；如果改了数据库作为主存，反倒会引起我们很大担心，且不说如何用范式化 schema 适应 nosql 的定义场景，字段映射的管理，元数据和实际内容的对应查看，引用完整性的潜在风险这些坑，光是实时分享版本改动引起的数据字段结构和值域定义更新问题，就成了一个麻烦。
- 还是那句话，思源笔记作为知识管理工具，而不是编辑排版工具的方向，非常认同；知识图谱的 schema，就是图；比起范式化的二维表，protege 这类知识定义 rdf 工具，是和 json 这种格式具有好得多的亲和力的，而且思源支持的 graphviz，可以直接和 protege 进行转换。
- 同样，也是期望思源尽快梳理出稳定的开发接口，sql 查询的数据库元数据和字典文档开放程度能更好一些，便于跟进；如果有一天，思源把主存储改为封闭数据库，不再坚持“本地 + 文本格式”，也希望及时告知，恕不能够继续一路升级同行了。
- 思源用户圈子建立很难得，大家场景不同，需求各异，求同存异不容易，一方面让开发者协调取舍，一方面多交流，理解，分享一些不改版本条件下解决问题的方法吧。
-
larryggao •支持者 订阅者
感谢，看了你对子文档的回复后，稍微对这个功能有点理解了。
这方面感觉官方做的不是很好，每次更新，都没有示例来说明新功能的作用、用法，完全靠用户自己瞎琢磨。
另外看了上面的“优质回帖”后，估计都是程序员背景，一些在程序员看起来非常容易的事情（比例搭个 git 这种），在非程序员的体验中是非常复杂的。思源如果只是做一款面向程序员的笔记软件，那也无可厚非。但是如果未来想走向“小白”类普通用户，还任重而道远！！！
1 回复 -
crowds21 •订阅者
是的,我也是这样认为, siyuan 对计算机以外的行业人员来说上手难度真的很大.
由于是 D 和 V 两个人开发,各种功能和进度都有些忙不过来了.具体示例只能靠社区的大家用爱发电了.
而且他们两的收入来源并不靠这个软件,所以未来很长一段时间内,这方面都不会有太大的改善.
请输入回帖内容
...