SurrealDB 图形数据库入门用关系查询替代复杂 JOIN【免费下载链接】surrealdbA scalable, distributed, collaborative, document-graph database, for the realtime web项目地址: https://gitcode.com/GitHub_Trending/su/surrealdbSurrealDB 图形数据库是一个用 Rust 编写的多模型数据库支持文档、关系与图形三种数据模型。它的 SurrealDB 关系查询让你可以直接在记录之间建立边并用一条语句沿边遍历多层数据适合社交关系、推荐、知识图谱等场景也适合想减少复杂 JOIN 的开发者。在关系型数据库里一旦数据涉及朋友的朋友的朋友这类多层关联写起来会明显变累每加一层关系就要多一次 JOIN 或子查询SQL 越写越长多对多关联用户-文章-评论容易引发 N1 问题即先查主表、再对每条记录单独查关联表循环引用甲认识乙、乙又认识甲需要额外处理否则会无限递归。而数据本身其实就是图节点是实体边是谁和谁有什么关系。SurrealDB 把这种直觉直接写进了查询语言让图形查询和建模保持同一种表达方式。哪些关系数据适合用它判断标准很简单你的实体之间是否存在方向 类型的连接。社交网络关注、好友、点赞都是带方向的关系边内容平台作者-文章-评论-回复层级较深且互相交叉知识图谱概念之间的是一种属于等语义关系风控与审计账户-转账-账户形成的链式追踪。如果你的业务主要是单表 CRUD图形模型意义不大一旦查关联开始占查询逻辑的大头图形遍历就会比 JOIN 更直观也更便于维护。图形查询为什么更直观SurrealDB 的核心概念只有三个记录类似文档带唯一 ID如user:alice边用RELATE语句在两条记录之间创建边本身也是一条记录可以存属性遍历SELECT时直接沿边走向下一层-表示方向。写一条关系RELATE user:alice-follows-user:bob;沿关系查询时方向读起来就是一句话从 alice 出发沿 follows 边到用户SELECT * FROM user:alice-follows-user;多层遍历同理链式书写即可无需再 JOIN 自己SELECT * FROM user:alice-knows*1..2;上面这条会取回 1 到 2 层之内的熟人网络。仓库中的 language-tests/tests/language/graph/ 目录收录了大量真实用例环检测、深度范围、菱形结构等可以拿来对照学习。新手如何快速体验用容器启动一个实例docker run --rm -p 8000:8000 surrealdb/surrealdb:latest start用任意 HTTP 客户端或 CLI 连接 8000 端口执行CREATE建两条记录、RELATE建一条边再执行沿边SELECT观察返回的边记录里in、out两个字段分别指向两端节点。跑通这三步后建议接着做两件事给边加属性比如SET since time::now()以及用WHERE在遍历中过滤这两步基本覆盖了日常用法。常见应用怎么落地社交关系分析。找共同好友可以写成从甲沿好友边走一步、再从对方反向走一步的链式查询一段语句拿到结果不用维护两张中间表。相似内容推荐。买过这台电脑的人还买了什么就是反向走到购买者、再正向走到他们买的其他商品方向相反的两段遍历即可表达。知识图谱。概念之间用is_a、part_of等自定义边类型连接边的类型天然就是语义标签检索时可以按边名过滤结构比关联表 类型字段更清晰。行为链路追踪。登录-支付-退款这类事件链每步是一条边按时间字段排序遍历就能还原完整路径。与传统方案相比要注意什么和纯关系型 JOIN以及专用图数据库相比选型时主要看这几点查询表达SurrealDB 的遍历写在一条 SELECT 里减少多次往返但边关系一旦建立跨库迁移要考虑边的存储方式模型混合同一库中图形、文档、全文检索可以并存适合不想拆多套存储的团队代价是单表超大规模分析场景仍需配套工具性能特征多层遍历的耗时随层数增长较快适合深度有限、宽度可控的查询不适合无界全图扫描生态位置如果系统已经在用 SurrealDB 存文档数据加图形能力成本很低若只是简单两级关联普通索引查询也够用。使用建议与性能提醒给高频遍历的边端点建索引避免全表扫描定位起点控制遍历深度用*1..3这类范围而不是开放深度大批量建边放在同一事务里提交减少反复写入实时场景可用LIVE SELECT订阅变更省去客户端轮询先在测试库验证遍历路径再上生产环状数据要设深度上限。下一步本地构建与运行环境配置参考 doc/BUILDING.md图形遍历的真实用例集在 language-tests/tests/language/graph/可逐文件阅读需要拉取源码时仓库地址为 https://gitcode.com/GitHub_Trending/su/surrealdb。建议的学习路径先跑通 RELATE 与沿边 SELECT再读几个 graph 用例文件最后把自己的一个真实关系表比如用户-关注迁移成节点 边模型对比一下查询写法的差异图形思维很快就能建立起来。【免费下载链接】surrealdbA scalable, distributed, collaborative, document-graph database, for the realtime web项目地址: https://gitcode.com/GitHub_Trending/su/surrealdb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 SurrealDB 图形数据库入门：用关系查询替代复杂 JOIN
SurrealDB 图形数据库入门用关系查询替代复杂 JOIN【免费下载链接】surrealdbA scalable, distributed, collaborative, document-graph database, for the realtime web项目地址: https://gitcode.com/GitHub_Trending/su/surrealdbSurrealDB 图形数据库是一个用 Rust 编写的多模型数据库支持文档、关系与图形三种数据模型。它的 SurrealDB 关系查询让你可以直接在记录之间建立边并用一条语句沿边遍历多层数据适合社交关系、推荐、知识图谱等场景也适合想减少复杂 JOIN 的开发者。在关系型数据库里一旦数据涉及朋友的朋友的朋友这类多层关联写起来会明显变累每加一层关系就要多一次 JOIN 或子查询SQL 越写越长多对多关联用户-文章-评论容易引发 N1 问题即先查主表、再对每条记录单独查关联表循环引用甲认识乙、乙又认识甲需要额外处理否则会无限递归。而数据本身其实就是图节点是实体边是谁和谁有什么关系。SurrealDB 把这种直觉直接写进了查询语言让图形查询和建模保持同一种表达方式。哪些关系数据适合用它判断标准很简单你的实体之间是否存在方向 类型的连接。社交网络关注、好友、点赞都是带方向的关系边内容平台作者-文章-评论-回复层级较深且互相交叉知识图谱概念之间的是一种属于等语义关系风控与审计账户-转账-账户形成的链式追踪。如果你的业务主要是单表 CRUD图形模型意义不大一旦查关联开始占查询逻辑的大头图形遍历就会比 JOIN 更直观也更便于维护。图形查询为什么更直观SurrealDB 的核心概念只有三个记录类似文档带唯一 ID如user:alice边用RELATE语句在两条记录之间创建边本身也是一条记录可以存属性遍历SELECT时直接沿边走向下一层-表示方向。写一条关系RELATE user:alice-follows-user:bob;沿关系查询时方向读起来就是一句话从 alice 出发沿 follows 边到用户SELECT * FROM user:alice-follows-user;多层遍历同理链式书写即可无需再 JOIN 自己SELECT * FROM user:alice-knows*1..2;上面这条会取回 1 到 2 层之内的熟人网络。仓库中的 language-tests/tests/language/graph/ 目录收录了大量真实用例环检测、深度范围、菱形结构等可以拿来对照学习。新手如何快速体验用容器启动一个实例docker run --rm -p 8000:8000 surrealdb/surrealdb:latest start用任意 HTTP 客户端或 CLI 连接 8000 端口执行CREATE建两条记录、RELATE建一条边再执行沿边SELECT观察返回的边记录里in、out两个字段分别指向两端节点。跑通这三步后建议接着做两件事给边加属性比如SET since time::now()以及用WHERE在遍历中过滤这两步基本覆盖了日常用法。常见应用怎么落地社交关系分析。找共同好友可以写成从甲沿好友边走一步、再从对方反向走一步的链式查询一段语句拿到结果不用维护两张中间表。相似内容推荐。买过这台电脑的人还买了什么就是反向走到购买者、再正向走到他们买的其他商品方向相反的两段遍历即可表达。知识图谱。概念之间用is_a、part_of等自定义边类型连接边的类型天然就是语义标签检索时可以按边名过滤结构比关联表 类型字段更清晰。行为链路追踪。登录-支付-退款这类事件链每步是一条边按时间字段排序遍历就能还原完整路径。与传统方案相比要注意什么和纯关系型 JOIN以及专用图数据库相比选型时主要看这几点查询表达SurrealDB 的遍历写在一条 SELECT 里减少多次往返但边关系一旦建立跨库迁移要考虑边的存储方式模型混合同一库中图形、文档、全文检索可以并存适合不想拆多套存储的团队代价是单表超大规模分析场景仍需配套工具性能特征多层遍历的耗时随层数增长较快适合深度有限、宽度可控的查询不适合无界全图扫描生态位置如果系统已经在用 SurrealDB 存文档数据加图形能力成本很低若只是简单两级关联普通索引查询也够用。使用建议与性能提醒给高频遍历的边端点建索引避免全表扫描定位起点控制遍历深度用*1..3这类范围而不是开放深度大批量建边放在同一事务里提交减少反复写入实时场景可用LIVE SELECT订阅变更省去客户端轮询先在测试库验证遍历路径再上生产环状数据要设深度上限。下一步本地构建与运行环境配置参考 doc/BUILDING.md图形遍历的真实用例集在 language-tests/tests/language/graph/可逐文件阅读需要拉取源码时仓库地址为 https://gitcode.com/GitHub_Trending/su/surrealdb。建议的学习路径先跑通 RELATE 与沿边 SELECT再读几个 graph 用例文件最后把自己的一个真实关系表比如用户-关注迁移成节点 边模型对比一下查询写法的差异图形思维很快就能建立起来。【免费下载链接】surrealdbA scalable, distributed, collaborative, document-graph database, for the realtime web项目地址: https://gitcode.com/GitHub_Trending/su/surrealdb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考