企业官网建设流程全解析

不写一行 JOIN 的关联查询？SurrealDB 图数据库上手

【免费下载链接】surrealdbA scalable, distributed, collaborative, document-graph database, for the realtime web项目地址: https://gitcode.com/GitHub_Trending/su/surrealdb

第一次听说 SurrealDB 支持图数据库能力时，我的反应是"又一个宣传词"。但把用户、文章和它们的关系真的建起来之后，我改变了想法：它的 RELATE 关系查询让关联可以按结构本身写出来，不用再去 JOIN。

如何用 RELATE 替代 JOIN：关联建模的第一步

关系型数据库里，表与表的关联只能靠查询时的 JOIN"发现"，数据本身没有结构。SurrealDB 的做法是把关联本身变成一条记录，用 RELATE 建出来：

CREATE user:tobie, article:surreal; RELATE user:tobie->write->article:surreal SET written = time::now();

这条边有自己的 id、能带任意字段。查询时沿边走即可，替代传统 JOIN 的关联查询在这一层就完成了：

SELECT ->write->article FROM user:tobie;

多层关联查询怎么写：从遍历到递归

边建好之后，多层关联不是"连接"而是"串接"。比如"朋友的朋友"：

person:tom->likes->person->likes->person;

每跳都可以带过滤条件，变量深度的情况则交给递归语法。例如沿边向外递归展开，并在最短路径到达目标节点时停住：

country:canada.{..+shortest=city:calgary}->next->?;

这类递归关系查询在普通 SQL 里很难表达，在图模型里只是一行。更多边角场景可以看 language-tests/tests/language/graph/ 下的测试用例。

什么时候值得选图数据库：选型时问自己三个问题

选型时我会问三件事：数据本身是不是网络（社交关系、知识图谱、调用链路）？多跳查询频不频繁？关系结构要不要长期保留？三个都是"是"，才值得用图模型——而 SurrealDB 的好处是它同时是文档数据库，建图不需要换库。

数据库变更如何被订阅：LIVE SELECT 的用法

让我意外的还有实时订阅。传统做法要么轮询、要么自建消息链路，SurrealDB 把它做成了标准语句：

LIVE SELECT * FROM user WHERE status = 'online';

订阅建立后，匹配的每条记录发生变更，连接着的客户端会直接收到推送。实时订阅数据库变更这件事，对在线状态、协同编辑这类功能来说省掉了一层基础设施。

有什么坑：什么时候不建议用

诚实说，它并不处处占优。递归遍历写起来轻松，但深度、广度失控的路径开销会迅速变大，给跳数设上限是基本操作。另外项目相对年轻，生产环境的版本升级节奏要自己留意，本地构建可以看 doc/BUILDING.md。如果你的业务是宽表报表、关联只有一两层，用成熟的关系数据库加 JOIN 更省心，不必硬套图模型。

建议你先挑业务里关联最复杂的一张表，用 RELATE 建边、写一条两跳的遍历查询试试手感——写完之后，值不值得整体采用，你心里会有数。

【免费下载链接】surrealdbA scalable, distributed, collaborative, document-graph database, for the realtime web项目地址: https://gitcode.com/GitHub_Trending/su/surrealdb