尧图网页设计 
SurrealDB图形数据库一次查询打通多层关系【免费下载链接】surrealdbA scalable, distributed, collaborative, document-graph database, for the realtime web项目地址: https://gitcode.com/GitHub_Trending/su/surrealdbSurrealDB 是一个用 Rust 实现的多模型数据库文档、图、搜索几种数据形态共用一个引擎。它的图形数据库能力把关系也变成可查询的数据用图形遍历查询替代层层嵌套的 JOIN社交网络、推荐这类场景一次查询就能拿到多层结果。一个组织架构图写崩了第几版 SQL公司通讯录最常见的两个需求查某人的汇报链查谁管着谁的反向树。表里只有employee.manager_id一列指向上级每多查一层就多拼一次 JOIN写四五层就是四五段重复递归 CTE 能收拢但加上过滤条件和维护成本SQL 很快没人敢动。更麻烦的是反向视角manager 指向下属是隐式的想按下属展开就得再写一套逻辑。放到客户端分页加载一个部门页就要 N1 次往返。根子在于传统方案里关系不是数据只是两表间靠外键暗示的连接每次要用的时候手工推演。SurrealDB 的做法是把边存成独立的记录节点、边都是可SELECT的对象路径直接写在语句里。三步建图节点、边、查询各一句话先建两个节点再用 RELATE 建边最后一条语句把边查回来CREATE employee:alice SET level 3; -- 起点节点 CREATE employee:carl SET level 1; RELATE employee:alice-reports_to-employee:carl SET started 2024-03-01; -- 边上挂入职时间 SELECT out FROM employee:alice-reports_to; -- 取这条边指向谁运行后得到[{ in: employee:alice, out: employee:carl }]。注意reports_to是一张真实的表RELATE 建边时会生成一个独立的边记录started这类字段就是它的属性后续能像查文档一样按它过滤、排序。进阶多跳、深度、最短路径一行写完多跳遍历person:alice-knows-person-knows-person就是朋友的朋友链式写几跳就查几跳深度限定person:alice.{1..3}-knows-person限定一到三跳遇到环不会失控最短路径person:alice.{..shortestperson:ceo}-reports_to-person从 alice 直达 CEO 的节点序列双向边person:alice-knows-person不关心方向找共同熟人常用条件过滤SELECT -knows-(person WHERE level 3) FROM employee:alice对下一跳的目标就地加约束聚合统计SELECT id, count(-knows) AS n FROM person直接统计每个人的出边数求和、均值同理把-knows当集合来聚合。更多写法可以看仓库里的 图形遍历测试用例。和关系型 JOIN 方案的差异在哪维度外键 JOIN 思路SurrealDB 图方式关系存放一列隐式外键独立边表自带属性层级每加一跳多拼一段 JOIN一条语句写任意跳数反向查询再写一遍 JOIN-换方向几字符的事路径语义靠递归 CTE 或应用层递归最短路径、深度限定是内建语法取数次数客户端按层加载时 N1 往返一次查询返回整棵子图差异不在谁快一点而在数据建模关系本身成为可增删、可加字段、可过滤的对象很多原本散在应用代码里的递归逻辑就回到了引擎内部。三个落地场景社交、推荐、图谱社交网络共同好友、二度人脉是社交产品最典型的查询。双向箭头天然处理我加了你、你加了我这种方向不一致的数据配合{1..n}深度限定控制返回量一层层加载主页关系图不用客户端递归。SELECT -knows-person AS direct, -knows-person-knows-person AS degree2 FROM person:alice;返回两个字段direct是一度好友列表degree2是二度关系集合。推荐系统买了 A 的人还买了什么不需要离线算好相似度矩阵才能用。把purchased建成边共购商品就是两条边交汇的中间节点再按边上的购买时间或数量过滤就能做时效性加权而这类条件在纯 JOIN 方案里往往要靠应用层聚合完成。SELECT -purchased-user-purchased-product FROM product:laptop;结果是和 laptop 存在共购关系的商品集合行数即候选推荐量。知识图谱 实时订阅概念、实体用节点存is_a、part_of用边存图谱的修订过程加概念、改分类就是普通的 DML。查询侧配合 LIVE SELECT订阅一条查询边或节点一变服务端就向所有客户端推增量前端不用轮询。RELATE concept:ml-is_a-concept:ai; LIVE SELECT * FROM concept WHERE -is_a;第一条返回建好的边记录第二条返回一个订阅句柄之后图谱里任何is_a边变动都会实时推到连接中的客户端。本地跑起来一行 Docker 最小示例本地验证不需要装任何东西一个镜像起单节点服务默认内存引擎数据不落盘够做原型docker run --rm -p 8000:8000 surrealdb/surrealdb:latest start服务监听 8000 端口的 HTTP 接口浏览器或 curl 都能直接调。然后跑最小闭环建两个节点、建一条边、查回来CREATE concept:ml, concept:ai; RELATE concept:ml-is_a-concept:ai; SELECT out FROM concept:ml-is_a;第三句输出[{ in: concept:ml, out: concept:ai }]说明边已建成且可遍历。什么时候该选它什么时候别选SurrealDB 的图能力解决的是关系即数据的建模问题层级深度不定、方向经常反转、边上要挂业务属性——这类需求比递归 CTE 省不少代码。但别把它当万能图引擎它的图功能面向中等规模的关系建模超大规模图计算、复杂的中心性分析等场景仍要考虑专门的图系统图数据库选型时把数据量和查询模式摆出来对比更稳妥。日常用法细节见 官方文档语法边界以仓库中的语言测试为准。【免费下载链接】surrealdbA scalable, distributed, collaborative, document-graph database, for the realtime web项目地址: https://gitcode.com/GitHub_Trending/su/surrealdb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 SurrealDB图形数据库：一次查询打通多层关系
SurrealDB图形数据库一次查询打通多层关系【免费下载链接】surrealdbA scalable, distributed, collaborative, document-graph database, for the realtime web项目地址: https://gitcode.com/GitHub_Trending/su/surrealdbSurrealDB 是一个用 Rust 实现的多模型数据库文档、图、搜索几种数据形态共用一个引擎。它的图形数据库能力把关系也变成可查询的数据用图形遍历查询替代层层嵌套的 JOIN社交网络、推荐这类场景一次查询就能拿到多层结果。一个组织架构图写崩了第几版 SQL公司通讯录最常见的两个需求查某人的汇报链查谁管着谁的反向树。表里只有employee.manager_id一列指向上级每多查一层就多拼一次 JOIN写四五层就是四五段重复递归 CTE 能收拢但加上过滤条件和维护成本SQL 很快没人敢动。更麻烦的是反向视角manager 指向下属是隐式的想按下属展开就得再写一套逻辑。放到客户端分页加载一个部门页就要 N1 次往返。根子在于传统方案里关系不是数据只是两表间靠外键暗示的连接每次要用的时候手工推演。SurrealDB 的做法是把边存成独立的记录节点、边都是可SELECT的对象路径直接写在语句里。三步建图节点、边、查询各一句话先建两个节点再用 RELATE 建边最后一条语句把边查回来CREATE employee:alice SET level 3; -- 起点节点 CREATE employee:carl SET level 1; RELATE employee:alice-reports_to-employee:carl SET started 2024-03-01; -- 边上挂入职时间 SELECT out FROM employee:alice-reports_to; -- 取这条边指向谁运行后得到[{ in: employee:alice, out: employee:carl }]。注意reports_to是一张真实的表RELATE 建边时会生成一个独立的边记录started这类字段就是它的属性后续能像查文档一样按它过滤、排序。进阶多跳、深度、最短路径一行写完多跳遍历person:alice-knows-person-knows-person就是朋友的朋友链式写几跳就查几跳深度限定person:alice.{1..3}-knows-person限定一到三跳遇到环不会失控最短路径person:alice.{..shortestperson:ceo}-reports_to-person从 alice 直达 CEO 的节点序列双向边person:alice-knows-person不关心方向找共同熟人常用条件过滤SELECT -knows-(person WHERE level 3) FROM employee:alice对下一跳的目标就地加约束聚合统计SELECT id, count(-knows) AS n FROM person直接统计每个人的出边数求和、均值同理把-knows当集合来聚合。更多写法可以看仓库里的 图形遍历测试用例。和关系型 JOIN 方案的差异在哪维度外键 JOIN 思路SurrealDB 图方式关系存放一列隐式外键独立边表自带属性层级每加一跳多拼一段 JOIN一条语句写任意跳数反向查询再写一遍 JOIN-换方向几字符的事路径语义靠递归 CTE 或应用层递归最短路径、深度限定是内建语法取数次数客户端按层加载时 N1 往返一次查询返回整棵子图差异不在谁快一点而在数据建模关系本身成为可增删、可加字段、可过滤的对象很多原本散在应用代码里的递归逻辑就回到了引擎内部。三个落地场景社交、推荐、图谱社交网络共同好友、二度人脉是社交产品最典型的查询。双向箭头天然处理我加了你、你加了我这种方向不一致的数据配合{1..n}深度限定控制返回量一层层加载主页关系图不用客户端递归。SELECT -knows-person AS direct, -knows-person-knows-person AS degree2 FROM person:alice;返回两个字段direct是一度好友列表degree2是二度关系集合。推荐系统买了 A 的人还买了什么不需要离线算好相似度矩阵才能用。把purchased建成边共购商品就是两条边交汇的中间节点再按边上的购买时间或数量过滤就能做时效性加权而这类条件在纯 JOIN 方案里往往要靠应用层聚合完成。SELECT -purchased-user-purchased-product FROM product:laptop;结果是和 laptop 存在共购关系的商品集合行数即候选推荐量。知识图谱 实时订阅概念、实体用节点存is_a、part_of用边存图谱的修订过程加概念、改分类就是普通的 DML。查询侧配合 LIVE SELECT订阅一条查询边或节点一变服务端就向所有客户端推增量前端不用轮询。RELATE concept:ml-is_a-concept:ai; LIVE SELECT * FROM concept WHERE -is_a;第一条返回建好的边记录第二条返回一个订阅句柄之后图谱里任何is_a边变动都会实时推到连接中的客户端。本地跑起来一行 Docker 最小示例本地验证不需要装任何东西一个镜像起单节点服务默认内存引擎数据不落盘够做原型docker run --rm -p 8000:8000 surrealdb/surrealdb:latest start服务监听 8000 端口的 HTTP 接口浏览器或 curl 都能直接调。然后跑最小闭环建两个节点、建一条边、查回来CREATE concept:ml, concept:ai; RELATE concept:ml-is_a-concept:ai; SELECT out FROM concept:ml-is_a;第三句输出[{ in: concept:ml, out: concept:ai }]说明边已建成且可遍历。什么时候该选它什么时候别选SurrealDB 的图能力解决的是关系即数据的建模问题层级深度不定、方向经常反转、边上要挂业务属性——这类需求比递归 CTE 省不少代码。但别把它当万能图引擎它的图功能面向中等规模的关系建模超大规模图计算、复杂的中心性分析等场景仍要考虑专门的图系统图数据库选型时把数据量和查询模式摆出来对比更稳妥。日常用法细节见 官方文档语法边界以仓库中的语言测试为准。【免费下载链接】surrealdbA scalable, distributed, collaborative, document-graph database, for the realtime web项目地址: https://gitcode.com/GitHub_Trending/su/surrealdb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考