组织机构树数据库表设计

公司需要做一个组织机构管理的系统,但是现有的数据库中存储的方式,机构之间的关联只是通过parent_id关联的,这样在查询的时候需要不断的递归查询表数据,性能很差,逻辑也不清晰。所以在网上找到了几种针对这种树状结构存储,查询插入的优化方法

1.发现几种树结构数据库存储方案

2.聊聊树状结构如何在数据库中存储

3.组织机构树设计

1.2两种有点复杂了,第三个连接有一位答主介绍了一种快捷查询的方法

 1 很麻烦的做法。
 2 简单的只需要在原表里加一列就行了:
 3
 4 组织机构简洁字段设计:
 5
 6 (ogran_code是组织机构唯一代码,真正的系统里都会有这东西的)
 7
 8 id,name,ogran_code,parent_id
 9
10 快速查询字段设计:
11
12 id,name,ogran_code,parent_id,code_link
13
14 (code_link是从根到该机构的整个code链条,例如: "root_code"+"first_code"+"child_code")
15 分隔符自定义即可
16 添加编辑机构时只关注该机构的父机构,在父机构的link上添加本机构的部分:  "pareat_code_link"+"local_code"
17
18 任何查询都可以通过这个字段快速完成。
19
20 1,某机构所有子机构,查询所有包含某机构CODE的CODE_LINK即可。可以使用like,超级简单。
21 2,查询Level,拆分该字段即可。
22
23 总之,很方便记录的一个链路LINK,可以做到任意需要递归才可以完成的查询。

 用图表分析了一下

  • 当插入(1总公司)

  id  code_link

  1  0_null_null

  • 在(1总公司)下插入(2上海分公司),总公司的child_code为2,上海分公司的root_code为1

  id  code_link

  1  0_null_2

  2  1_null_null

  • 在(1总公司)下插入(3深圳分公司),总公司的child_code为2,3,上海分公司的root_code为1

  id  code_link

  1  0_null_2,3

  2  1_null_null

  3  1_null_null

  • 在(2上海分公司)下插入(4徐汇办事处),上海分公司的child_code为4,徐汇办事处的first_code为2

  id  code_link

  1  0_null_2,3

  2  1_null_4

  3  1_null_null

  4  1_2_null

  • 在(2上海分公司)下插入(5闵行办事处),上海分公司的child_code为4,5,闵行办事处的first_code为2

  id  code_link

  1  0_null_2,3

  2  1_null_4,5

  3  1_null_null

  4  1_2_null

  5  1_2_null

  • 在(3深圳分公司)下插入(6人事部),深圳分公司的child_code为6,人事部的first_code为3

  id  code_link

  1  0_null_2,3

  2  1_null_4,5

  3  1_null_6

  4  1_2_null

  5  1_2_null

  6  1_3_null

  • 在(3深圳分公司)下插入(7财务部),深圳分公司的child_code为6,7,财务部的first_code为3

  id  code_link

  1  0_null_2,3

  2  1_null_4,5

  3  1_null_6,7

  4  1_2_null

  5  1_2_null

  6  1_3_null

  7  1_3_null

  • 在(4徐汇办事处)下插入(8研发部),徐汇办事处的child_code 为8,研发部的first_code为2,4(带上徐汇办事处的first_code 2)

  id  code_link

  1  0_null_2,3

  2  1_null_4,5

  3  1_null_6,7

  4  1_2_8

  5  1_2_null

  6  1_3_null

  7  1_3_null

  8  1_2,4_null

  • 在(4徐汇办事处)下插入(9市场部),徐汇办事处的child_code 为8,9,市场部的first_code为2,4(带上徐汇办事处的first_code 2)

  id  code_link

  1  0_null_2,3

  2  1_null_4,5

  3  1_null_6,7

  4  1_2_8,9

  5  1_2_null

  6  1_3_null

  7  1_3_null

  8  1_2,4_null

  9  1_2,4_null

  • 在(9市场部)下插入(10市场调研小组),市场部的child_code为10,市场调研小组的first_code为2,4,9(带上市场部的first_code)

  id  code_link

  1  0_null_2,3

  2  1_null_4,5

  3  1_null_6,7

  4  1_2_8,9

  5  1_2_null

  6  1_3_null

  7  1_3_null

  8  1_2,4_null

  9  1_2,4_10

  10   1_2,4,9_null

至此,查询一个机构的子机构只需查询root_code和first_code中含有此节点id的数据

例如,查询(2上海分公司)的子机构,则为4,5,8,9,10

查询(4徐汇办事处)的子机构,则为8,9,10

原文地址:https://www.cnblogs.com/blog-cq/p/10733011.html

时间: 2024-10-07 11:05:36

组织机构树数据库表设计的相关文章

无限树形结构的数据库表设计

前言: 无限树形结构的数据库表设计的是否合理,直接影响到UI层是否方便根据树来查询关联的数据. 1.表字段: F_BtEd2kTypeId int Unchecked F_Name nvarchar(50) Checked F_ParentTypeId nvarchar(50) Checked F_Code nvarchar(50) Checked F_RecordStatus int Checked 2.表数据: 3.说明: 如2所示, 1)如果上表的数据关联上了一张表A,通过BtEd2kTy

20170105数据库表设计知识点

20170105数据库表设计知识点 ------指导老师    星哥 1.PHP(MYSQL)擅长单表操作,不要做过多无谓的连接查询 2.表字段名不要使用大驼峰命名方式,最好采用下划线,命名要和团队习惯一致,通俗易懂. 3.表级.字段都要有注释 4.MyISAM 适合于一些需要大量查询的应用,但其对于有大量写操作并不是很好.甚至你只是需要update一个字段,整个表都会被锁起来,而别的进程,就算是读进程都无法操作直到读操作完成.另外,MyISAM 对于 SELECT COUNT(*) 这类的计算

数据库表设计三范式

数据库设计三范式(nomorlization) 1NF:原子性,即每个字段都不可以在分割了. 2NF:唯一性,即每个表只描述一个实体,这个实体要有主键,非主关键字要完全依赖主键,正因为说是完全依赖,是因为在组合主键存在的情况下,非主关键字不能只依赖部分关键字. 3NF:一个表中不能包含其他表中已经存在的非主键字段信息,也就是说只可以包含其他表的主键信息,这样就是主外键,通过主外键就可以进行表之间的连接(join),3NF主要是减少数据冗余. 数据库表设计三范式,布布扣,bubuko.com

Innodb IO优化 — 数据库表设计 转

数据库表设计这块学问比较多,我这里单从互联网角度出发同时结合Innodb的特性给出一些设计方法供大家参考.本文构建大概分两分部分:Innodb的特性及设计中如何利用这种特性. Innodb特性: Innodb是索引聚集表, 存储结构是BTREE Innodb的表的数据存储是有顺序的,默认是以主建排序,主建即是数据本身,不单独存放. 如果没有主建,Innodb以第一个唯一索引排序,如果连唯一索引也没,Innodb内部会产生一个6字节的字段排序(这个也是性能杀手,所以对这块如果不想花太多时间去想这个

Oracle数据库表设计时的注意事项

表是Oracle数据库中最基本的对象之一.万丈高楼从平地起,这个基础对象对于数据库来说,非常重要.因为其设计是否合理,直接跟数据库的性能相关.从Oracle数据库菜鸟到数据库专家这个过程中,在表设计与管理上,或多或少,会犯一些错误.笔者今天就谈谈自己在这方面的经验与教训,或许能够给大家一些警示作用. 表是Oracle数据库中最基本的对象之一.万丈高楼从平地起,这个基础对象对于数据库来说,非常重要.因为其设计是否合理,直接跟数据库的性能相关.从Oracle数据库菜鸟到数据库专家这个过程中,在表设计

数据库表设计的很灵活,是否做SQL语句也那么容易呢

由于项目需要,我们把一些不经常变的常数通过数据字段配置好,系统初始化的时候通过数据库字段去更新数据.下面就实例说明. 我有一张这样的表 ,你会发现meterkindid和measureid是代码,只有通过数据配置的数据字典才能解析出我们要的值,下面为数据字典表结构 ,这样设计就很灵活,FieldID为列名称,ID为上面表的值,value为解析值,也就是代码对应的名称,下面再发一张字典的数据图 MK001和MK002对应数据字典的水表跟电表,MS001和MS002对应数据字典的计量单位分别为吨还是

用户权限管理数据库表设计思想

用户权限管理数据库表设计思想 表:(1)用户表(user) (2)权限表(power) (3)部门表(group) (4)角色表(role) (5)用户部门角色表(user_group_role)存放用户id,部门id,角色id (6)权限部门角色表(power_group_role)存放权限id,部门id,角色id 设计理念: a用户可以(绑定)属于m部门n角色   z权限可以(绑定)属于m部门n角色 由此:a就拥有z权限 设计扩展:一个用户可以同时属于多个部门下的多个角色 每个部门下的每个角

数据库设计:用户登录系统数据库表设计

用户登录系统数据库表设计 最近看了看公司后台用户登录系统的设计, 比较混乱, 主要还是因为URS和Oauth以及URS第三方这三个登录形式各不相同导致的. 下面着重介绍一下涉及到第三方登录中需要注意的问题 在一个新项目中, 如果是要建立自己的登录体系的话, 那么直接创建一个Users表,包含username和password两列,这样,就可以实现登录了: id | username | password | name等其他字段 ----+----------+----------+-------

转一篇MYSQL文章《数据库表设计,没有最好只有最适合》

http://mp.weixin.qq.com/s/a8klpzM5iam0_JYSw7-U4g 我们在设计数据库的时候,是否会突破常规,找到最适合自己需求的设计方案,下面来举个例子: 常用的邻接表设计,都会添加 一个 parent_id 字段,比如区域表(国.省.市.区): CREATE TABLE Area ( [id] [int]  NOT NULL, [name] [nvarchar]  (50) NULL, [parent_id] [int]  NULL, [type] [int]