邻接表想必大家都不陌生吧,用邻接表的关键是,在每个节点存储他的父节点的id。
在每一个部门信息中都存储了他的父节点id,parent_id字段
导入数据的过程就不说了,直接来看下数据吧:
这里使用常用的几种查询方式来看下这种方案的查询
可以通过parent_id做查询条件,可以快速查询到一个部门的直属下级部门
通过部门信息中的parent_id去查相应的父节点信息就可以快速实现
这种数据存储结构下,更新数据是比较方便快捷的,添加数据时直接找准父节点的id,组织部门变更时,也直接变更父id就好了,删除时候,看自己业务是否需要删除子节点这几种情况,
路径标的要点,就是每个节点存储根节点到该节点的路径,其实我觉得和别的几种方案可以共用
在每一个部门信息中都存储了他完整的路径,path字段
导入数据的过程就不说了,直接来看下数据吧:
使用路径表,通过path这个字段查询起来是比较困难的,一般都需要使用like,CONCAT函数、REPLACE函数等做字符串的处理逻辑,查询起来比较复杂,这里不做展示了,线上服务不建议使用这种方式,查询效率低会影响到服务性能,一般建议和邻接表方式统一使用,同时添加parent_id和path字段,parent_id用来查询,path用来查看节点完整的路径
这种数据存储结构下,更新数据是比较方便快捷的,添加数据时直接找准路径就好,组织部门变更时,也直接找准路径就好,删除时候,看自己业务是否需要删除子节点这几种情况,
Closure Table,百度直译过来叫闭合表,大多数人叫做闭包表,这种方案的要点是存储公司部门信息主表中,不存储节点关系的数据,使用另一张关系表来存储节点之间的关系,其中包含了任何两个有关系(上下级)节点的关联信息
公司部门信息主表,只需要存储部门的本身信息
主要包括三个字段
要点就是关系表的一条记录是一个上级节点、下级节点、与他们之间的路径距离。拿部门结构图来举例子
总公司-企划部的关系数据是:
总公司-大区A的关系数据是:
关系表中存储所有的节点路径信息,还用distance表示路径的距离,需要把树形结构中每两个节点之间的路径信息都维护进来。
数据存储的过程就拿导入总公司-门店A的过程做个示例。主表的数据存储就不说,说下关系中,存储部门结构的路径信息,总公司-门店A总共包含以下几条路径:
看到了么,是存储了所有总公司-门店A之间的路径信息
这里使用常用的几种查询方式来看下这种方案的查询
这种数据存储结构下,更新数据比较麻烦,因为他存储了两节点直接所有路径信息(包括中间节点的)
8.文件需要是二进制文件8.定义数据库表结构为struct,里面可以任意定义你要的帐号密码余额。多个的话,定义成链表link.8.写两个函数用来读和写这个文件,序列化 *** 作文件。8.写文件时把struct的内容逐次写入...假设有如下一棵树:
要存储于数据库中,最简单直接的方法,就是存储每个元素的父节点ID。
暂且把这种方法命名依赖父节点法,因此表结构设计如下:
存储的数据如下格式:
这种结构下,如果查询某一个节点的直接子节点,十分容易,比如要查询D节点的子节点。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)