缘起
本文主要是总结本人在 SuperRef 和动态数据库的应用方面的实践心得，还有本人一些不太成熟的思考。本文之所以能够出现，要感谢 F 佬（Frostime）设计制作的两大突破性的数据库应用工具：SuperRef 和 动态数据库。
-
欲了解这两个工具，以及了解本文所述的核心内容，必须先通读以下两篇文章：
- SuperRef：将反向链接和数据库结合的尝试
- 动态数据库：尝试通过查询语句来动态构建数据库
-
这两个工具被 F 佬装进同一个插件 F's 工具箱 里，也可以说，它们其实是一体的。
-
关于 F's 工具箱（即 F-misc），其实它还有很多强大的功能，比如 AI GPT 对话，这里不另行展开。
-
欲实现在思源笔记的侧边栏管理 SuperRef 与动态数据库，还需安装 F 佬制作的另一个插件：
注意：一定要在已有 SuperRef 或动态数据库的情况下，再使用书签 + 添加相对应的侧边栏查询代码，一定不要让书签 + 代码产生“空值”。
-
SuperRef 的特点是“专一”（一个块引绑定一个数据库），所以它的应用场景较容易想到（后文再细说）。而动态数据库则不然，它既能“锁定”关键词，也能“锁定”标签，还能锁定多个；由于它是基于 JS 代码的，它的应用更加灵活，但由此带来的困惑也更多——动态数据库到底该怎么用？
这个问题从该工具被创造出来时就已存在。（以下内容引自《尝试通过查询语句来动态构建数据库》）
不过说实话，我自己尝试几天后，发现这个功能的定位有点尴尬。
……这种动态构建数据库的方案上不去下不来，感觉有点鸡肋。到底实际价值有多大，就交给其他人来自行评判了。
即使 F 佬本人对动态数据库的功能定位提出过质疑，但它仍是一个突破性的工具。
我在 SuperRef 刚发布时，还是一个对 SQL 查询代码一窍不通的萌新。由于当时对反链和数据库的认知不足，对 SuperRef 的应用完全没有头绪，纯粹就是一个建好了摆着看看的工具。直到动态数据库发布，我才正式开始在笔记中应用这两种工具。直到现在，总算略有心得。
本文的初衷也是对自己的应用心得进行总结，以期梳理自己的思路，发现更多关于这两个突破性工具的用法。同时，也践行——输出，才是消化魔药知识的最快途径。
由于本人对 SQL、JS 等专业知识的了解非常浅薄（只通了半窍），所以本文所涉及的只是普通应用思路的层面，距离更深入的功能探索，以及形成方法论，还有很长的路要走。
由于本人水平有限，本文难免不足和谬误，请大家不吝斧正。
应用环境中存在的问题
本文的核心在于工具的应用，所以欲了解本文所述，首先要了解本文所述的 SuperRef 和 动态数据库 这两个工具，及其应用环境。但这个话题太大，以下只就相关联的部分，略作阐述。
从 SiYuan 的三大标记工具说起
思源笔记有三个标记工具：
-
第一个标记工具：标签。 这是最传统的标记工具，大部分的笔记都有。但在思源里，却一直处于比较尴尬的地位。主要是思源的标签管理面板功能性不足，基本依赖思源本体强大的全局搜索功能。
-
第二个标记工具：双链（块引）。 这是当代笔记的革命性标记工具，正是由于双链的出现，使得标签能做的事，双链也能做到，某种意义上让思源中标签这个工具的地位变得比较尴尬了。
-
第三个标记工具：数据库。思源的数据库本身是一个强大的信息管理的工具，但巧妙的是，它其实还可以当成标记工具和属性面板来用。
-
所有被添加到数据库的内容块的右上角，都会出现一个数据库角标，这是一种很特别的标记。
-
鼠标在角标上悬浮，会弹出数据库页面；点击角标，会弹出数据库信息（属性面板）。
（效果展示详见后文）
-
然而，问题来了。
思源的这三个标记工具中，只有数据库标记能够进行信息拓展，它能够在内容块的元信息以外，通过创建新的数据表单项，拓展更多额外“属性”。而标签、双链，在这方面却有先天性的不足。
存在的问题：缺失的维度
标签管理的现状
-
思源的标签管理面板有点简陋
- 全靠思源本身强大的全局搜索功能。
-
标签管理所缺失的维度
- 缺少筛选、过滤功能；
- 缺少更便捷的管理功能；
- 缺少拓展额外信息的功能。
双链管理的现状
-
思源的双链管理相对较完善
-
双链管理所缺失的维度
- 缺少拓展额外信息的功能。
“额外信息”到底是指什么
他山之石，可以攻玉。要弄明白这个问题，最直接的方式就是看看其他笔记软件有什么更出色的表现。这就不得不提 Tana 带来的 SuperTag，超级标签了。
SuperTag 赋予了传统标签新的功能，让普通标签能拥有一套属于自身的信息结构（变成像属性一样），还能在列表中展开，相当于给每个标签绑定了一个数据库。这个数据库不仅能以子列表的形式展开，还能让子标签直接继承母标签的信息结构（属性）。
- （以下内容引自《Tana：2022 最惊艳的笔记软件》）
Tana 的节点在 Supertag 的帮助下有了类似 Notion 的字段和列表视图，更进一步的，它也可以拥有像 Notion 一样的表格、画廊或者日历视图，你可以自由地在不同视图（View）之间切换。
而思源本身所具备的三大标记工具之间是割裂的，没能打通。
曙光：SuperRef 和动态数据库的突破
于是，F 佬针对这一问题，制作了 SuperRef 这一突破性工具。（以下内容引自《将反向链接和数据库结合的尝试》）
🤔 核心的问题在于，双链关系本身缺乏描述性的语义信息。……在传统的反链面板中，这些链接在语义上并没有明显的区分。
这里的关键点在于两个：
- 自下而上地生长： 表格结构的形成源于零散的笔记内容聚合积累，而不是在预先设定的顶层页面中手动逐行添加结构。
- 关联关系的元属性： 这是传统反向链接（包括思源的反向链接）所欠缺的。 传统反链只提供简单的链接关系，而缺乏对关系本身进行自定义属性描述的能力。
SuperRef 的意义恰恰在于：将双链（块引）与数据库结合起来，由此，赋予了双链（块引）拓展额外信息的功能。
深度使用思源的双链（块引）后，我们就会发现，仅靠反链面板或底部反链来管理复杂、多层交叉的反链，仍有不足。
同时，当我们在正链的位置进行悬浮浏览时，虽然能看到所链接的对象（文档内容），但对于我们当初为什么要链接到这一对象，经常需要自己“脑索”最初的记忆了。问题就在于，时常会想不起来。
而假如双链所在的块，本身能够通过绑定的数据库来添加额外信息，假如这信息里又有一项是“为什么连接到[[AAA]]”，那问题不就简单了。
后来，F 佬又在发布《尝试通过查询语句来动态构建数据库》的同时，推出了动态数据库，进一步将数据库与标签结合起来，甚至还将数据库与关键词查询也结合起来。
这样一来，思源的三大标记工具之间就被初步打通了，甚至这种突破还延伸到了关键词查询，让思源数据库的功能得到了质的提升。
恍然：且谈我最初的思维误区
在我最初使用 SuperRef 时，受以前使用思源数据库的旧有经验局限，曾一度陷入一个思维误区。在看过《Tana：2022 最惊艳的笔记软件》一文后，我终于才真正读懂了 F 佬的话（引自《尝试通过查询语句来动态构建数据库》）：
我认为 Super Tag 的核心要点在于：将自下而上的引用方式与自上而下的数据库管理逻辑融合，从而实现了自下而上地构建数据库。
以下是一个恍然大悟自己已经走了弯路的人的反思：
-
突然发现自己之前的一个思维误区：只是把数据库当成分类表、状态表、进度表来使用。今天看了关于 SuperTag 的介绍才发现，我错了。
-
每一个 SuperRef 或动态数据库，应该都是精心设计的信息框架。
-
应该让数据库真正成为高价值信息库，必须要精心设计，应该探索更丰富的用法。
- 比如
[[书]]或#book产生的 SuperRef 或动态数据库，可以展开类似豆瓣读书数据库一样的书籍信息。 - Ideas 数据库，也应该展开关于灵感的更深入思考的内容，而不只是后续处理的阶段。
- 应该把这类 SuperRef 或动态数据库，作为概念属性（思考拓展）的信息载体。
- 比如
然后，我迫不及待地修改了我的 SuperRef 数据库。修改之前，我的 SuperRef 数据库是这样的：
初步修改之后，是这样的：
而在正链所在的块，右上角的数据库角标是这样的（特殊效果来自数据库数据展示插件）：
数据库属性面板是这样的：
当然，这只是未经实践的拍脑袋式修改。
本想略过的基础应用介绍
由于 F 佬已经在 《将反向链接和数据库结合的尝试》与 《尝试通过查询语句来动态构建数据库》讲述了 SuperRef 与动态数据库的用法，所以，我本想省掉这一块（实际也没打算详细展开）。但觉得仍有一些个人的应用心得，可以与大家分享交流一下。
SuperRef 的基础应用
-
操作步骤：详见 《将反向链接和数据库结合的尝试》
-
几点提示与建议
-
绑定的双链所对应的文档，可以是新文档，也可以是旧文档，但最好（必须？）是空文档。
- 旧文档原有内容可以复制到一个副本中，如果直接用旧文档生成 SuperRef 数据库，原有内容可能会被覆盖。
- 建议先在空文档中生成 SuperRef 数据库，生成后，可再自行添加其他内容。
-
绑定的双链所对应的文档，还可设定别名，让语义相同但表达不同的块引，归于一库。
- 比如 Todo 文档，我就设定了
待办、未来记录等别名。
- 比如 Todo 文档，我就设定了
-
创建数据库之前，所有已建立的同一块引，会在数据库创建时自动添加到库中。但
- 创建数据库之后，再建立的块引，就需要在数据库块标的右键菜单里点
插件 - 更新SuperRef数据库才能更新到数据库中了。 - F-misc v5.7.2 版本起，可在 F-misc 的
设置 - 其他设置中勾选自动刷新 SuperRef 数据库，可在打开对应文档的时候，自动刷新 SuperRef 数据库。
- 创建数据库之后，再建立的块引，就需要在数据库块标的右键菜单里点
-
动态数据库的基础应用
-
操作步骤：详见 《尝试通过查询语句来动态构建数据库》
-
基础的查询代码（来源同上，有改动）
-
关键词查询（示例）
//!js const blocks = await sql("SELECT * FROM blocks where (type='p' or type='d' or type='h') and (content LIKE '%关键词A%' or content LIKE '%关键词B%'"); return blocks.map(b => b.id); -
标签查询（示例）
//!js const blocks = await sql("SELECT * FROM blocks WHERE (type='p' OR type='d' OR type='h') AND (tag LIKE '%#标签A#%' or tag LIKE '%#标签B#%'"); return blocks.map(b => b.id);
-
-
我的最初体会
-
标签式动态数据库很有用，更有利于对标签对象进行管理。
- 用数据库后，可以设置不同的筛选视图，并给标签对象的情况加额外属性。
- 对于普通的标签，可以不需要这一步；但对于有后续管理动作的标签，动态数据库就很有用了。
-
关键词动态数据库，使一些特定的日常札记的收录，更加便捷。
-
比如，我偶尔会在日记中记录自己做的梦，以前需要右键送到相应数据库。虽然也可以用 SuperRef ，但会多一个动作。
-
现在，只要描述前有
@做梦：，这一段落块就自动添加到记录梦的数据库了。对于日常札记这种很普通的事来说，完全不需要有多余的动作，只要记录的内容中有特定的表述就行了。- 注意：用特殊符号包裹关键词，是我最新的用法，这样可以最大限度地避免误录普通使用该词汇的内容块。
- 最开始，我用的是“做了个梦”或“做了一个梦”，这样的方式还是会有误录。
-
这一方式不足是，关键词不能过于通用（简单），否则如果别的文章里刚好大量使用了该词，那就是“灾难”了。
-
-
创建数据库之前，所有已添加的标签（关键词），会在数据库创建时自动添加到库中。但
- 创建数据库之后，再添加的标签（关键词），就需要在数据库块标的右键菜单里点
插件 - 更新动态数据库才能更新到数据库中了。 - F-misc v5.7.2 版本起，可在 F-misc 的
设置 - 其他设置中勾选自动刷新动态数据库，可在打开对应文档的时候，自动刷新动态数据库。
- 创建数据库之后，再添加的标签（关键词），就需要在数据库块标的右键菜单里点
-
SuperRef 与动态数据库的区别
-
SuperRef
-
通过双链（块引）建立数据库，一对一，悬浮时还可看到下文。
-
适用场景
- 单一主题、单一概念、单一类型（但可有多个别名）
- 前提：主题（概念）具有独立性，有独立的数据结构，即与其他同级概念无法共用相同的表头，需要单独设立数据库，比如[[图书]]、[[影视剧]]、[[思源应用]]等。
-
-
动态数据库
-
通过标签/关键词建立数据库，可多对一。纯粹的一对一，不如用 SuperRef。
-
适用场景
- 多个子概念，对应到一个大类（数据库）。
- 前提：各个子概念，应用上确实会存在差异，但底层需求结构（或逻辑结构）是一致的，因而对应的数据结构基本一致，可用同一套表头。
-
例子
-
动态数据库出来之前，我把
[[闪念]]、[[灵感]]、[[选题]]这三个块引，各绑定了一个 SuperRef 数据库。- 阵容很豪华，但非常不经济。
-
动态数据库出来后，我把原来用块引标记的方式，分别改用
#闪念、#灵感、#选题来标记，然后绑定到了同一数据库，并将之命名为 Ideas 数据库。
-
-
进阶应用初探：通过区别看本质
以上浅析了 SuperRef 与动态数据库的区别，在简化表述下，约等于：
-
SuperRef：一对一建立块引数据库。
- 虽可用别名间接关联多个词，但绑定 SuperRef 的块引所呈现的词，仍是唯一的。
-
动态数据库：多对一建立标签数据库，或关键词数据库。
所以，这就是一对一与多对一的关系吗？并没有这么简单。
SuperRef 的应用场景初窥
-
SuperRef 的应用场景
-
写作：[[作品标题]]绑定 SuperRef
- 收集写作素材时
- 产生写作灵感时
- 想到新的段子时
-
项目：[[项目名称]]绑定 SuperRef
- 项目所需资源
- 项目阶段目标
- 项目阶段成果
-
主题 MOC 反链的自动汇总
- MOC 主题的块引一般是唯一的，虽然手动 MOC 更有价值，但偷懒的话，也可以用 SuperRef 来进行汇总。
-
笔记应用
- [[思源应用]]：绑定 SuperRef，可将所有收集到与思源应用有关的技巧、引述、代码，统一入库。
- [[思源问题]]：绑定 SuperRef，将遇到的思源笔记问题、BUG，及解决方法，统一入库。
-
Daily Note 流相关的标记
- [[ToDo]]：给 Daily Note 中的待办事项打标记，绑定 SuperRef 自动入库。
- [[备忘]]：给 Daily Note 中需要日后备查的事项打标记，绑定 SuperRef 自动入库。
-
更多……（懒得想了-_-!）
-
动态数据库：又一个“小问题”
我在上文给出了动态数据库的基础查询代码，这个代码其实是放在动态数据库弹窗提示中的，我只是根据 《尝试通过查询语句来动态构建数据库》一文图片中的代码，略作修改，增加了 OR 语句，初步实现了标签、关键词内容的多对一入库。
- 这也是我最初用的代码，当时我没有跑通 F 佬图片中的代码，只好先做了折中。
但后来我在应用过程中发现，这个折中的基础代码是基于 SQL 查询的，由于限定了只查询文档块、标题块、段落块（通过 WHERE (type='p' OR type='d' OR type='h') 代码），所以如果标签（关键词）所在的块是列表块的话，在数据库对应主键的悬浮弹窗里，默认就只会显示标签（关键词）所在的那一个段落的内容。
-
即使标签（关键词）就是列表块的第一项，也不会显示它的子列表项。
-
虽然在数据库对应主键的悬浮弹窗里，我们可以通过点击右上角的“上下文”按钮，来展开当前段落块的上下文，但这毕竟要多一步操作，不是很方便。
-
我也曾经尝试过增加
OR type='l'（列表块），但它会与段落块的内容重复被汇入数据库（即出现重复项）。所以，这个方法不太好用。
查询的“核动力”：Query & View
其实，针对这个“小问题”，F 佬已经给出了解决方案，就是用 Query View 代码来搜索，因为 Query View 具备重定向链接机制，通过“容器块传递”代码，能轻松解决这个问题。
- 关于重定向链接机制，请自行参阅 F 佬的关于 Query View 的文章。
就在写本文之前，我经过学习与反复尝试，终于在 Query View 基础代码的框架下，将查询代码改成了 QV 语法的代码，能在悬浮时展现标签所在的列表块了：
-
注意：以下代码需要安装 Query & View插件，因为必须要 Query & View插件来提供语法支持。
-
关键词查询 QV 代码（示例）
//!js const query = async () => { const SQL = ` select * from blocks where (type='p' or type='d' or type='h') and (content like '%@短关键词：%' or content like '%长关键词%') `; let blocks = await Query.sql(SQL); blocks = await Query.fb2p(blocks); return blocks.pick('id'); } return query(); -
标签查询 QV 代码（示例）
//!js const query = async () => { const SQL = ` select * from blocks where (type='p' or type='d' or type='h') and (tag like '%#标签A#%' or tag like '%#标签B#%') `; let blocks = await Query.sql(SQL); blocks = await Query.fb2p(blocks); return blocks.pick('id'); } return query();
动态数据库的应用场景初窥
-
动态数据库的应用场景
-
关键词自动收集
-
反思、复盘、做梦、美食等日常记录，可通过关键词来自动收集。
-
关键词最好前后用特殊符号前后包裹（比如用
@……：来包裹），避免误录。- 也可以用别的特殊符号，但最好是容易输入的，方便日常操作。
-
可将多个关键词汇总到一个数据库里。
-
-
标签自动收集
-
常规用法：N 个标签一个数据库来管理
-
在查询代码中，用 OR 来汇总多个标签到一个数据库。
- 适合对意义相近的一组标签进行统一管理。
- 减少数据库冗余，减少对数据库的关注度。
-
-
常规用法，一定意义上可以说，是动态数据库存在的原因。
- 如果没有“多对一”的需求，那为什么不直接用 SuperRef 呢？
- 如果只有一个标签，那我完全可以用块引来代替标签，将块引直接绑定数据库。
-
-
最初时，我的动态数据库应用仅限于此。某天，在修改一个动态书签 SQL 代码时，我突然想到：
- 我动态数据库代码用的是 OR 来组合标签，如果用 AND 来组合标签，会怎样呢？
OR，还是 AND，这是个问题
在冒出这个念头的那一刻，我就被这个想法迷住了。当时就把闪念记了下来：
-
我们应该用更丰富的方式来使用动态数据库。
-
方法 A：用 OR，来让多个不同标签的对象，汇总到同一数据库。
-
方法 B：用 AND，必须要同时有二个（或以上）标签的对象，才能进入指定数据库。又可分成两种用法：
- 用法 B1：只有单个
标签A时并不想让对象入库，但再加一个标签B后就能入库。 - 用法 B2：只有单个
标签A时对象进入库A，再加一个标签B后就再次进入库B。
- 用法 B1：只有单个
-
有趣的正是用法 B2，即同时满足 N（N≥2）个标签，会再次进到另一个数据库。
-
这意味着什么呢？
-
我们先来看用法 B1。
-
用法 B1：我觉得，它可以叫阻拦式动态数据库。
-
其意义在于：某些标签，你并不想它一开始就入库，只有加上第 2 个标签时，它才会入库。
- 那为什么不直接去管理第 2 个标签，这不是更简单吗？（很好的吐槽）
- 直接管理第 2 个标签，有可能让其他不相关的场景也进入指定数据库。
- 比如以下的例子，如果不用 AND 来附加
#美食标签，那有可能让与美食无关但又标记了#请客标签的内容进入到美食相关的数据库。
- 这只是一个特殊的例子，如果没这方面的顾虑，那完全可以只管理第 2 个标签（又或是块引）。
- 那为什么不直接去管理第 2 个标签，这不是更简单吗？（很好的吐槽）
-
我们来看一个例子（纯假设）：
-
如
#美食标签，打这个标签，可能只代表你吃过。- 当你自己会做这道美食时，你再打上
#菜谱标签，它才会进入 “下厨菜谱”数据库。 - 对那些只吃过却不会做，但你认为可以用来招待亲友客人的，你再打上
#请客标签，它就会进入“美食社交”数据库。 - 最后，肯定还有一些虽然打上了
#美食，但你既没兴趣学烹饪，也基本不会再去光顾的，就可以让它保持静默，在日记里潜伏躺平，等待被唤醒。
- 当你自己会做这道美食时，你再打上
-
之所以要分不同的数据库，而非合在一个库里用不同视图来管，是因为“下厨菜谱”与“美食社交”的属性应该是截然不同的，分开两个数据库来管理，更方便，不会混乱。
-
-
但如果不是上面这种涉及不同结构的数据库的情况，那还是直接用 SuperRef 吧。
-
-
-
那用法 B2 呢？我觉得，它的应用场景更广泛，也更实用。
或许该叫它：阶梯式动态数据库
-
阶梯式动态数据库：组合标签时合并使用 OR 与 AND
-
具体做法：某个或某些（后者应该更常用，用 OR 写入查询代码中）标签（也可以是关键词，甚至还可以标签与关键词混用），刚开始让它（们）进入
库A； -
由此，会“自动”汇总一批加了指定标签（关键词）的记录；
-
当你决定对其中某一条记录采取进一步行动时，再用 AND 给它追加一个进阶标签，它就会同时进入
库B。- 这个内容块，在添加进阶标签后，会同时进入两个库——
库A和库B。 - 关键：
库A和库B有不同的数据结构，不同的表单项和视图，承担不同的管理职能。
- 这个内容块，在添加进阶标签后，会同时进入两个库——
-
甚至还可以进一步进入
库C……以此类推。 -
举个我自己实践的例子：
-
前文说了，我用 IDeas 动态数据库来同时管理
#闪念、#灵感、#选题。-
其实，它们都是灵感，只是“灵”的程度有所不同。
- 闪念：我定义为某个瞬间的想法，但我暂时没想明白它该如何拓展，乃至它的意义；又或者它暂时没有拓展的必要。
- 灵感：更接近传统意义上的灵感，我在想到它的时候已经明了其意义，以及大致的拓展方向，只是还需要时间深入思考。
- 选题：同样是灵感，但比较成熟，我既明了它的意义，也知道要如何拓展它，只需要时间来将它写成文章或笔记。
-
它们的属性相同（因为本质上是一样的），有一致的数据结构。
-
在数据库属性面板上，它们是这样呈现的：
-
它们被我同时汇总到了 IDeas 库，用不同的视图来分别管理——通过制定不同视图的筛选条件，就能实现。
-
-
-
对于其中重要的灵感或选题，当我要立即着手来推进它时，我会再给它打上
#重要标签。这时，这条内容会再次进入 Doing 库，Doing 库会赋予它另一套与行动相关的属性。而这条内容原本的属性也依然保留着。-
这些属性会同时呈现在该内容块的数据库属性里，而且很有层次感。
-
在内容块本身，加上之前提到的数据库数据展示插件效果，它的呈现是这样的：
-
如果有必要，我还可以用同样的方法，让它继续进入第 3 个库、第 4 个库。
- 个人觉得，这个数据库流非常 cool！至少我个人很喜欢它的实践效果，它达到了我的预期！
-
-
同时，这也就实现了阶梯式的动态数据库应用 。
-
-
阶梯式动态数据库的应用场景
（短时间内，我能想到的有）
-
创作类场景
-
第一步记录思想、灵感，第二步组织行动——这是所有创作的底层模式。
-
它们都可用阶梯式动态数据库来管理（参照我上面的实例）。
- 比如：写作、编程、办讲座、做视频、做直播……。
-
-
复杂项目场景： 也可以采用这种模式。
因为这类项目，往往每个阶段，有不同的属性，所以不同阶段有可能需要用不同数据库来管理。
-
比如：买房、炒股。
-
前期看房（选股），信息是一套内容属性，你可能会记录很多房源（股票）信息。
-
中期买房（买股），信息又有新增内容，但可能只有 1 套房子（几个股票）进入到第二个购买数据库。
- 这时，你需要新增一套内容属性，但原属性在原来的数据库里会继续存在，你不用重复创建。
- 新增的属性只会在第二套库里存在，不会干扰第一个库。
-
后期装修（抛股），信息又会截然不同。
- 这时你只要从容的建一个新库，增加一个 AND 条件，不用考虑如何优化以前的数据库了。
-
-
-
其他……
-
结语
以上就是我近 2 个月内，实践 SuperRef 与动态数据库的一些粗浅心得，以及我自己想到的一些用法。附上阶梯式动态数据库的 QV 查询代码（示例中用于 Doing 数据库的），供大家参考：
//!js
const query = async () => {
const SQL = `
select * from blocks where (type='p' or type='d' or type='h')
and (tag like '%#闪念#%' or tag like '%#灵感#%' or tag like '%#选题#%')
and tag like '%#重要#%'
`;
let blocks = await Query.sql(SQL);
blocks = await Query.fb2p(blocks);
return blocks.pick('id');
}
return query();
我又有一计
如果我们在需要的时候，给 SuperRef 对应的内容块，也打上一个特定的进阶标签，让它自动关联另一个动态数据库，效果会怎样呢？
想到就做：
SuperRef 与动态数据库的属性面板，也融合在一起了！
原来如此
真相是，思源的普通数据库之间，本身就能进行这种数据库属性面板的融合。
-
竟然今天才知道，思源的数据库竟然还有这样好用的特性。
-
这个特性可以用在任何一种阶梯式的数据库管理上。
- 因而，普通数据库也能够与 SuperRef 和动态数据库进行类似的融合，也就不意外了。
-
但一些特殊数据库，主要是插件生成的数据库，有可能会融合不了。（不再展开）
结语的结语
以上，就是我个人使用 SuperRef 和动态数据库的些许心得，在此抛砖引玉。希望能给刚开始使用这两个工具的朋友一点启发；也希望更多高手达人，能分享对这两个工具的用法心得，让我也能借鉴提升。
【本文完】
欢迎来到这里！
我们正在构建一个小众社区，大家在这里相互信任，以平等 • 自由 • 奔放的价值观进行分享交流。最终，希望大家能够找到与自己志同道合的伙伴，共同成长。
注册 关于