1. 数据库设计三大范式
在设计关系数据库的时候，一般来说我们都是需要遵从不同的规范要求来设计出合理的关系型数据库，这些不同的规范要 求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。
范式分为：3大范式，以及BC范式，第四范式还有第五范式 一共六大范式通常来说满足与三大范式就基本足够 ；
注意：项目的数据库设计并不一定要完全满足与三大范式，有些时候我们会适量的冗余让Query尽两减少Join
误区:不是范式越高越就越好 好 => 结构清晰
早期:希望数据可以足够的小数据量不是问题主要分问题
现在:希望查询速度越快越好,同时操作越简单越好
1.1 第一范式（1NF）
简单地说，第一范式要求关系中的属性必须是原子项，即不可再分的基本类型，集合、数组和 结构不能作为某一属性出现，严禁关系中出现“表中有表”的情况在任何一个关系数据库系统中，第一范式是关系模 式的一个最起码的要求。不满足第一范式的数据库模式不能称为关系数据库。
原始表中，其中”工程地址”列还可以细分为省份，城市等。在国外，更多的程序把”姓名”列也分成2列,即”姓”和“名”。
虽然第一范式要求各列要保存原子性，不能再分，但是这种要求和我们的需求是相关联的，如上表中我们对”工程地址”没有省份，城市这样方面的查询和应用需求，则不需拆分，”姓名”列也是同样如此。
原始表:
| 工程号 | 工程名称 | 工程地址 | 员工编号 | 员工名称 | 薪资待遇 | 职务 |
|---|---|---|---|---|---|---|
| P001 | 港珠澳大桥 | 广东珠海 | E0001 | Jack | 6000/月 | 工人 |
| P001 | 港珠澳大桥 | 广东珠海 | E0002 | Join | 7800/月 | 工人 |
| P001 | 港珠澳大桥 | 广东珠海 | E0003 | Apple | 8000/月 | 高级技工 |
| P002 | 南海航天 | 海南三亚 | E0001 | Jack | 5000/月 | 工人 |
1.2 第二范式（2NF）
第二范式（2NF）是在第一范式（1NF）的基础建立起来的，既满足第二范式（2NF）就必须要 满足第一范式。第二范式（2NF）要求实体的属性完全依赖于主键字。
第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。简而言之，第二范式就是在第一范式的基础上属性完全依赖于主键。
例如：原始表中描述了工程信息，员工信息等。这样就造成了大量数据的重复。按照第二范式，我们可以将原始表分为工程信息表与员工信息表
工程信息表：
| 工程编号 | 工程名称 | 工程地址 |
|---|---|---|
| P001 | 港珠澳大桥 | 广东珠海 |
| P002 | 南海航天 | 海南三亚 |
员工信息表：
| 员工编号 | 员工姓名 | 职务 | 薪资水平 |
|---|---|---|---|
| E0001 | Jack | 工人 | 3000/月 |
| E0002 | Join | 工人 | 3000/月 |
| E0003 | Apple | 高级技工 | 6000/月 |
1.3 第三范式（3NF）
第三范式（3NF）是第二范式的子集，既满足第三范式就必须满足第二范式。意思是不存在非 关键字段对任意候选关键字段的传递函数依赖
例如：现在我们来看看在第二范式的讲解中，我们将表1-1拆分成了两张表。这两个表是否符合第三范式呢。在员工信息表中包含：”员工编号”、”员工名称”、”职务”、”薪资水平”，而我们知道，薪资水平是有职务决定，这里”薪资水平”通过”职务”与员工相关，则不符合第三范式。我们需要将员工信息表进一步拆分，如下:
员工信息表：
| 员工编号 | 员工姓名 | 职务编号 |
|---|---|---|
| E0001 | Jack | 1 |
| E0002 | Join | 1 |
| E0003 | Apple | 2 |
工程信息表：
| 工程编号 | 工程名称 | 工程地址 |
|---|---|---|
| P001 | 港珠澳大桥 | 广东珠海 |
| P002 | 南海航天 | 海南三亚 |
职务表(Duty)
| 职务编号 | 职务名称 | 工资待遇 |
|---|---|---|
| 1 | 工人 | 3000/月 |
| 2 | 高级技工 | 6000/月 |
工程参与人员记录表：
| 编号 | 工程编号 | 人员编号 |
|---|---|---|
| 1 | P001 | E0001 |
| 2 | P001 | E0002 |
| 3 | P002 | E0003 |
通过对比我们发现，表多了，关系复杂了，查询数据变的麻烦了，编程中的难度也提高了，但是各个表中内容更清晰了， 重复的数据少了，更新和维护变的更容易了。
不推荐存储的数据类型
- 二进制多媒体数据 将二进制多媒体数据存放在数据库中，一个问题是数据库空间资源耗用非常严重，另一个问题是 这些数据的存储很消耗数据库主机的CPU 资源。这种数据主要 包括图片，音频、视频和其他一些相关的二进制文件。 这些数据的处理本不是数据的优势，如果我们硬要将他们塞入数据库，肯定会造成数据库的处理资源消耗 严重。
- 流水队列数据 我们都知道，数据库为了保证事务的安全性（支持事务的存储引擎）以及可恢复性，都是需要记录所 有变更的日志信息的。而流水队列数据的用途就决定了存放 这种数据的表中的数据会不断的被 INSERT，UPDATE 和 DELETE，而每一个操作都会生成与之对应的日志信息。在 MySQL 中，如果是支持事务的存储引擎，这 个日志的产生量 更是要翻倍。而如果我们通过一些成熟的第三方队列软件来实现这个 Queue 数据的处理功能，性能将会成倍的提升。
- 超大文本数据 对于 5.0.3 之前的 MySQL 版本，VARCHAR 类型的数据最长只能存放 255 个字节，如果需要存储 更长的文本数据到一个字段，我们就必须使用 TEXT 类型（最大 可存放 64KB）的字段，甚至是更大的LONGTEXT 类型 （最大 4GB）。而 TEXT 类型数据的处理性能要远比 VARCHAR 类型数据的处理性能低下很多。从 5.0.3 版 本开始 ，VARCHAR 类型的最大长度被调整到 64KB 了，但是当实际数据小于 255Bytes 的时候，实际存储空间和实际的数据长 度一样，可一旦长度超过 255 Bytes 之后，所占用的存储空间就是实际数据长度的两倍。 对于图片的存储，如果说是 特殊情况可以使用BLOB，但是通常来说跟推介使用varchar存图片路径，而图片会放在一个文件夹中