不写一行 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.{..shortestcity: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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 不写一行 JOIN 的关联查询？SurrealDB 图数据库上手
不写一行 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.{..shortestcity: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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考