mysql-索引、关系、范式
索引
- 几乎所有的索引都是建立在字段之上
- 索引:系统根据某种算法,将已有的数据(未来可能新增的数据也算),单独建立一个文件,这个文件能够快速的匹配数据,并且能够快速的找到对应的表中的记录
索引意义
- 能够大幅度提升查询数据的效率
- 约束数据的有效性、唯一性等
索引前提
- 增加索引的前提条件:索引本身会产生索引文件,这个索引文件有可能会比数据文件还大,会比较消耗磁盘空间
- 如果某个字段需要作为查询条件经常使用,那么可以使用索引,索引根据需求想办法增加
- 如果某个字段需要进行数据的有效性约束,也可能使用索引(主键约束、唯一键约束)
- mysql中提供了很多索引
- 主键索引:primary key
- 唯一键索引:unique key
- 全文索引:fulltext index
- 普通索引:index
关系
- 将实体与实体的关系,反应到最终数据库表的设计上,所有的关系都是指表与表之间的关系
- 关系分为三类:一对一、一对多、多对多
一对一
一张表的一条记录只能与另外一张表的一条记录进行对应,反之亦然
案例
学生表: 包括姓名,性别,年龄,身高,体重,婚姻状况, 籍贯, 家庭住址,紧急联系人这些字段
ID(P) | 姓名 | 性别 | 年龄 | 身高 | 体重 | 婚姻状况 | 籍贯 | 家庭住址 | 紧急联系人 |
---|---|---|---|---|---|---|---|---|---|
1 | |||||||||
2 |
表设计成以上这种形式: 符合要求. 其中姓名,性别,年龄,身高,体重属于常用数据; 但是婚姻,籍贯,住址和联系人属于不常用数据. 如果每次查询都是查询所有数据,不常用的数据就会影响效率, 实际又不用.
- 解决方案
- 将常用的和不常用的信息分离存储,分成两张表
常用信息表:姓名,性别,年龄,身高,体重
ID(P) 姓名 性别 年龄 身高 体重 1 2 不常用信息表:保证不常用信息与常用信息一定能够对应上: 找一个具有唯一性(确定记录)的字段来共同连接两张表
ID(P) 婚姻状况 籍贯 家庭住址 紧急联系人 1 2 总结:一个常用表中的一条记录: 永远只能在一张不常用表中匹配一条记录;反过来,一个不常用表中的一条记录在常用表中也只能匹配一条记录: 一对一的关系
一对多
一张表中有一条记录可以对应另外一张表中的多条记录; 但是返回过, 另外一张表的一条记录只能对应第一张表的一条记录. 这种关系就是一对多或者多对一
案例
母亲与孩子的关系: 母亲,孩子两个实体
母亲和孩子两个实际之间的关系: 一个妈妈可以在孩子表中找到多条记录(也有可能是一条); 但是一个孩子只能找到一个妈妈: 是一种典型的一对多的关系.
母亲表
[ ] ID(p) 名字 年龄 1 2 孩子表
[ ] ID(p) 名字 年龄 1 2 这种设计解决了实体的设计表问题, 但是没有解决关系问题: 孩子找不出妈,妈也找不到孩子
- 解决方案
- 在某一张表中增加一个字段,能够找到另外一张表的中记录: 应该在孩子表中增加一个字段指向妈妈表: 因为孩子表的记录只能匹配到一条妈妈表的记录
修改孩子表,母亲表不变
ID(P) 姓名 年龄 性别 母亲ID 1 母亲表主键 2 母亲表主键
多对多
一张表中(A)的一条记录能够对应另外一张表(B)中的多条记录; 同时B表中的一条记录也能对应A表中的多条记录: 多对多的关系
案例
老师和学生
老师表
T_id(P) | 姓名 | 性别 |
---|---|---|
1 | ||
2 |
- 学生表
S_id(P) | 姓名 | 性别 |
---|---|---|
1 | ||
2 |
这种设计弊端:实现了实体的设计, 但是没有维护实体的关系,一个老师教过多个学生; 一个学生也被多个老师教过
解决方案
在学生表中增加老师字段: 不管在哪张表中增加字段, 都会出现一个问题: 该字段要保存多个数据, 而且是与其他表有关系的字段, 不符合表设计规范,所以此时应该增加一张新表: 专门维护两张表之间的关系
就是增加一个表,用来维护老师和学生的关系
老师表
T_id(P) | 姓名 | 性别 |
---|---|---|
1 | ||
2 |
- 学生表
S_id(P) | 姓名 | 性别 |
---|---|---|
1 | ||
2 |
- 中间关系表,维护老师和学生之间的关系
id(P) | T_ID(P) | S_ID(P) |
---|---|---|
1 | 1 | 1 |
2 | 2 | 2 |
3 | 1 | 2 |
增加中间表之后: 中间表与老师表形成了一对多的关系: 而且中间表是多表,维护了能够唯一找到一表的关系; 同样的,学生表与中间表也是一个一对多的关系: 一对多的关系可以匹配到关联表之间的数据
学生找老师: 找出学生id -> 中间表寻找匹配记录(多条) -> 老师表匹配(一条)
老师找学生: 找出老师id -> 中间表寻找匹配记录(多条) -> 学生表匹配(一条)
范式
- 范式: Normal Format, 是一种离散数学中的知识, 是为了解决一种数据的存储与优化的问题: 保存数据的存储之后, 凡是能够通过关系寻找出来的数据,坚决不再重复存储: 终极目标是为了减少数据的冗余.
- 范式: 是一种分层结构的规范, 分为六层: 每一次层都比上一层更加严格: 若要满足下一层范式,前提是满足上一层范式
- 六层范式: 1NF,2NF,3NF...6NF, 1NF是最底层,要求最低;6NF最高层,最严格
- Mysql属于关系型数据库: 有空间浪费: 也是致力于节省存储空间: 与范式所有解决的问题不谋而合: 在设计数据库的时候, 会利用到范式来指导设计.
- 但是数据库不单是要解决空间问题,要保证效率问题: 范式只为解决空间问题, 所以数据库的设计又不可能完全按照范式的要求实现: 一般情况下,只有前三种范式需要满足.
- 范式在数据库的设计当中是有指导意义: 但是不是强制规范
1NF(原子性)
- 第一范式: 在设计表存储数据的时候, 如果表中设计的字段存储的数据,在取出来使用之前还需要额外的处理(拆分),那么说表的设计不满足第一范式
- 第一范式要求字段的数据具有原子性: 不可再分
2NF(解决部分依赖)
- 第二范式: 在数据表设计的过程中,如果有复合主键(多字段主键), 且表中有字段并不是由整个主键来确定, 而是依赖主键中的某个字段(主键的部分): 存在字段依赖主键的部分的问题, 称之为部分依赖: 第二范式就是要解决表设计不允许出现部分依赖
- 解决方案
- 将表中存在部分依赖的字段分别拎出来单独创建表
- 取消复合主键、业务主键,使用逻辑主键
3NF(解决传递依赖)
- 第三范式: 理论上讲,应该一张表中的所有字段都应该直接依赖主键(逻辑主键: 代表的是业务主键), 如果表设计中存在一个字段, 并不直接依赖主键,而是通过某个非主键字段依赖,最终实现依赖主键: 把这种不是直接依赖主键,而是依赖非主键字段的依赖关系称之为传递依赖. 第三范式就是要解决传递依赖的问题"
- 要满足第三范式,必须满足第二范式
满足第二范式,必须满足第一范式
- 解决方案
- 将存在传递依赖的字段,以及依赖的字段本身单独取出,形成一个单独的表, 然后在需要对应的信息的时候, 使用对应的实体表的主键加进来
其实就是多对多的时候,解决
逆规范法
- 有时候, 在设计表的时候,如果一张表中有几个字段是需要从另外的表中去获取信息. 理论上讲, 的确可以获取到想要的数据, 但是就是效率低一点. 会刻意的在某些表中,不去保存另外表的主键(逻辑主键), 而是直接保存想要的数据信息: 这样一来,在查询数据的时候, 一张表可以直接提供数据, 而不需要多表查询(效率低), 但是会导致数据冗余增加
- 逆规范化: 磁盘利用率与效率的对抗
mysql-索引、关系、范式的更多相关文章
- MYSQL索引结构原理、性能分析与优化
[转]MYSQL索引结构原理.性能分析与优化 第一部分:基础知识 索引 官方介绍索引是帮助MySQL高效获取数据的数据结构.笔者理解索引相当于一本书的目录,通过目录就知道要的资料在哪里, 不用一页一页 ...
- 【转】MySQL索引背后的数据结构及算法原理
摘要 本文以MySQL数据库为研究对象,讨论与数据库索引相关的一些话题.特别需要说明的是,MySQL支持诸多存储引擎,而各种存储引擎对索引的支持也各不相同,因此MySQL数据库支持多种索引类型,如BT ...
- [转]MySQL索引背后的数据结构及算法原理
摘要 本文以MySQL数据库为研究对象,讨论与数据库索引相关的一些话题.特别需要说明的是,MySQL支持诸多存储引擎,而各种存储引擎对索引的支持也各不相同,因此MySQL数据库支持多种索引类型,如BT ...
- MySQL索引背后的数据结构及算法原理
摘要 本文以MySQL数据库为研究对象,讨论与数据库索引相关的一些话题.特别需要说明的是,MySQL支持诸多存储引擎,而各种存储引擎对索引的支持也各不相同,因此MySQL数据库支持多种索引类型,如BT ...
- MySQL索引的Index method中btree和hash的优缺点
MySQL索引的Index method中btree和hash的区别 在MySQL中,大多数索引(如 PRIMARY KEY,UNIQUE,INDEX和FULLTEXT)都是在BTREE中存储,但使用 ...
- mysql 索引2
/* 所有MySQL列类型可以被索引.根据存储引擎定义每个表的最大索引数和最大索引长度. 所有存储引擎支持每个表至少16个索引,总索引长度至少为256字节.大多数存储引擎有更高的限制. 索引的存储类型 ...
- mysql 索引及其原理
mysql 索引 KEY与INDEX的区别: KEY is something on the logical level, describes your table and database desi ...
- [纯干货] MySQL索引背后的数据结构及算法原理
摘要 本文以MySQL数据库为研究对象,讨论与数据库索引相关的一些话题.特别需要说明的是,MySQL支持诸多存储引擎,而各种存储引擎对索引的支持也各不相同,因此MySQL数据库支持多种索引类型,如BT ...
- MySQL 索引背后的数据结构及算法原理
本文转载自http://blog.jobbole.com/24006/ 摘要本文以MySQL数据库为研究对象,讨论与数据库索引相关的一些话题.特别需要说明的是,MySQL支持诸多存储引擎,而各种存储引 ...
- 浅谈MySQL索引背后的数据结构及算法
摘要 本文以MySQL数据库为研究对象,讨论与数据库索引相关的一些话题.特别需要说明的是,MySQL支持诸多存储引擎,而各种存储引擎对索引的支持也各不相同,因此MySQL数据库支持多种索引类型,如BT ...
随机推荐
- shell的case语句
case语句格式 # vi test.sh : echo "input : " read num echo "the input data is $num" c ...
- 分布式进阶(十一) Docker 常见错误汇总
NO.1 以上添加网桥的命令在Ubuntu14.04中是不可行的.正确的命令如下: brctl addbr br0 ifconfig br0 192.168.1.188 netmask 255.255 ...
- Android scrollview嵌套webview滑动冲突的解决方案
在Android开发中有时我们需要在scrollview中嵌套webview这时你会发现这两者的滑动事件产生了冲突导致:webview很难被滑动,即使被滑动了一点也非常不顺畅.解决方案也比较简单只需要 ...
- Android 免Root实现Apk静默安装,覆盖兼容市场主流的98%的机型
地址:http://blog.csdn.net/sk719887916/article/details/46746991 作者: skay 最近在做apk自我静默更新,在获取内置情况下,或者已root ...
- MacBook 最近发现的一些问题和技巧
本猫的mba最近键盘莫名会失灵,但用鼠标切换其他用户时时好的,切换回来又不行,体现如下: 1.Spotlight里可以输入,其他不可以 2.cmd+tab可以切换进程 现在只有重启后才可以恢复. 网上 ...
- Android系统修改硬件设备访问权限
Android系统修改硬件设备访问权限 在硬件抽象层模块文件(so)文件中,提供的函数调用open函数来打开设备文件,比如/dev/gpio,如果不修改设备文件/dev/gpio的访问权限,那么应用程 ...
- AngularJS进阶(四)ANGULAR.JS实现下拉菜单单选
ANGULAR.JS: NG-SELECT AND NG-OPTIONS PS:其实看英文文档比看中文文档更容易理解,前提是你的英语基础还可以.英文文档对于知识点讲述简明扼要,通俗易懂,而有些中文文档 ...
- C++中重载、覆盖与隐藏的区别(转)
本文摘自林锐博士的<高质量C++/C编程指南>. 成员函数的重载.覆盖(override)与隐藏很容易混淆,C++程序员必须要搞清楚概念,否则错误将防不胜防. 1.重载与覆盖 成员函数被重 ...
- Android Camera开发系列(上)——Camera的基本调用与实现拍照功能以及获取拍照图片加载大图片
Android Camera开发系列(上)--Camera的基本调用与实现拍照功能以及获取拍照图片加载大图片 最近也是在搞个破相机,兼容性那叫一个不忍直视啊,于是自己翻阅了一些基本的资料,自己实现了一 ...
- Smali语法汇总(一)
Opcode 操作码(hex) Opcode name 操作码名称 Explanation 说明 Example 示例 00 nop 无操作 0000 - nop 01 move vx, vy 移动v ...