MYSQL无限级分类表设计及自我连接

我们有这样一个需求:

做一个城市联动,比如说贵州省,省下面有众多市,市下面有众多区县,区县下面有众多镇,如果用多张表来存储,必然是能够简单的实现联动效果,但是多表的联合查询必然会影响到一些效率,此时可以考虑

用一张表来实现。

还有当我们要分的级数是不确定的,或者是很多的,那么建立多张表也是不合理的设计。

如何用一张表来存储呢?

该表的建立代码如下:

 1 create table city(id smallint unsigned auto_increment primary key,
 2 city_name varchar(20) not null ,parent_id smallint unsigned not null);
 3
 4 insert into city(city_name,parent_id) values("贵州",0);
 5 insert into city(city_name,parent_id) values("贵阳",1);
 6 insert into city(city_name,parent_id) values("遵义",1);
 7 insert into city(city_name,parent_id) values("铜仁",1);
 8 insert into city(city_name,parent_id) values("云南",0);
 9 insert into city(city_name,parent_id) values("昆明",4);
10 insert into city(city_name,parent_id) values("丽江",5);
11 insert into city(city_name,parent_id) values("四川",0);
12 insert into city(city_name,parent_id) values("成都",8);
13 insert into city(city_name,parent_id) values("浙江",0);
14 insert into city(city_name,parent_id) values("宁波",10);
15 insert into city(city_name,parent_id) values("河南",0);
16 insert into city(city_name,parent_id) values("郑州",12);
17 insert into city(city_name,parent_id) values("开封",12);
18 insert into city(city_name,parent_id) values("安阳",12);

我用了三个字段,其中parent_id存储的是父级的id,相当于是一个指针,指向父级。比如贵州,id为1,其中有贵阳,遵义,铜仁的parent_id为1,表示的含义为贵州省下有这三个城市。

为什么要有parent_id来指向父节点呢?我们来看看下面这张表。

就这张表而言,你能看出什么来?能看出成都是四川下的一个 市么?所以parent_id字段是必不可少的。

整张表是一个森林的数据结构,那么我们怎么查询到一个省下有多少个城市呢?

select p.id,p.city_name,s.city_name from city as p left join city as s on
 p.id=s.parent_id;

结果如下:

其中

select p.id,p.city_name,s.city_name表示查询出来的表只显示着三个字段,p代表父表,s代表子表。那么明明只有一张表,从何而来父表与子表呢?这就是所谓的自身连接。

你可以在脑海中想像另外一张表,该表和city表一模一样,然后像操作两张表一样将他们通过条件连接起来,此时我的条件就是p.id=s.parent_id;
left join表示左连接,意思就是父表的数据全部显示,子表的数据如果不存在则显示为空,比如上面显示的,郑州,我们通过p.id=s.parent_id没有查询到父表的id与子表的parent_id相同,于是父表的数据(13,郑州)

完全显示出来,子表的数据显示为空。
时间: 2024-10-12 14:50:32

MYSQL无限级分类表设计及自我连接的相关文章

MySQL基础入门学习【9】无限级分类表设计

比如: 图书/小说.文学.../四大名著.戏曲.../... 理论上可以设计很多张表: 但是随着分类逐步增多,这些表的数目不可能无限扩展: 所以对于无限级分类表一般我们采用如下形式(通过自身的连接来实现的): 这个例子中我们至少设计三个字段: 分类的id.分类的名称.父类的id. 插入记录: INSERT tdb_goods_types(type_name,parent_id) VALUES('家用电器',DEFAULT); INSERT tdb_goods_types(type_name,pa

MySQL技巧(二)——无限级分类表设计

无限级分类表的设计(掌握'自身连接') 类似图书这种,会有很多种分类,而且在现实生活中这种分类会无限的往下分,所以不可能每有一个分类就创建一个分类表.应该使用下面这种语句 DROP TABLE IF EXISTS tdb_goods_types; CREATE TABLE tdb_goods_types( type_id SMALLINT PRIMARY KEY AUTO_INCREMENT COMMENT '分类ID', type_name VARCHAR(50) COMMENT '分类名称'

mysql无限级分类实现基于汇报关系的信息管理权限

汇报关系和家族族谱的实现类似,采用树的数据结构进行定义,树采用递归进行定义.即要嘛是一个根节点,要嘛是由一个根节点和其子树组成.OA中的汇报关系也采用这种结构(与树稍有不同),除董事长外,其他人有且只有一个非其本人的直接主管,董事长的直接主管和越级主管是其本人.从以上的定义其实可以看出,汇报关系类似树,但又与树并不完全相同.除董事长外,其他汇报关系均是树形结构.树形结构采用递归定义,如采用递归查询是非常耗时的操作.比如以下需求: 1.主管可以看到所有直线下属的绩效信息: 针对以上需求,我们提出三

mysql 无限级分类实现思路

第一种方案: 使用递归算法,也是使用频率最多的,大部分开源程序也是这么处理,不过一般都只用到四级分类. 这种算法的数据库结构设计最为简单.category表中一个字段id,一个字段fid(父id).这样可以根据WHERE id = fid来判断上一级内容,运用递归至最顶层. 分析:通过这种数据库设计出的无限级,可以说读取的时候相当费劲,所以大部分的程序最多3-4级分类,这就足以满足需求,从而一次性读出所有的数据,再对得到数组或者对象进行递归.本身负荷还是没太大问题.但是如果分类到更多级,那是不可

基于ExtJs6前台,SpringMVC-Spring-Mybatis,resteasy,mysql无限极表设计,实现树状展示数据(treepanel)

先从后台讲起 1.表的设计 parent_id就是另外一条记录的id,无限极表设计可以参考  http://m.blog.csdn.net/Rookie_Or_Veteran/article/details/75711386 2.mysql查询很容易,关键是要把id,text,parentId查出来 <?xml version="1.0" encoding="UTF-8" ?><!DOCTYPE mapper PUBLIC "-//myb

MySQL数据库 多表查询 交叉连接 自然连接 内连接 自连接 外连接 子查询 多表查询练习 单表查询练习 &#109806;

原文: http://blog.gqylpy.com/gqy/466 置顶:来自一名75后老程序员的武林秘籍--必读(博主推荐) 来,先呈上武林秘籍链接:http://blog.gqylpy.com/gqy/401/ 你好,我是一名极客!一个 75 后的老工程师! 我将花两分钟,表述清楚我让你读这段文字的目的! 如果你看过武侠小说,你可以把这个经历理解为,你失足落入一个山洞遇到了一位垂暮的老者!而这位老者打算传你一套武功秘籍! 没错,我就是这个老者! 干研发 20 多年了!我也年轻过,奋斗过!我

MySQL的多表设计

一.外键约束 保证数据的完整性. 定义外键约束: 可以直接在create语句中定义外键 foreign key 当前表名(字段名) references 目标表名(目标表的主键) 创建完语句后,可以直接使用修改语句定义 alter table 表名 add foreign key 当前表名 (字段名) references 目标表名(目标表的主键) 二.多表设计的三种实体关系 多对多.一对多和一对一 三.多表设计之---------一对多 一个班级可以有多个学生,但是一个学生只能属于一个班级.或

mysql 无限级分类

两种思路吧,递归 和 非递归 递归 $arr = [ 1=>['id'=>1,'pid'=>0], 2=>['id'=>2,'pid'=>0], 3=>['id'=>3,'pid'=>1], 4=>['id'=>4,'pid'=>1], 5=>['id'=>5,'pid'=>0], 6=>['id'=>6,'pid'=>3], 7=>['id'=>7,'pid'=>6], 8=&g

mysql数据库关系表设计原则

https://blog.csdn.net/qq_36432666/article/details/78934073 https://kb.cnblogs.com/page/138526/ http://blog.sina.com.cn/s/blog_a29f7cb50101jr5d.html https://www.cnblogs.com/mjbrian/p/6841226.html https://blog.csdn.net/persistencequxi/article/details/7