MySQL高级篇-11-数据库的设计规范

数据库设计

糟糕的数据库设计

• 数据冗余、信息重复，存储空间浪费
• 数据更新、插入、删除的异常
• 无法正确表示信息
• 丢失有效信息
• 程序性能差

良好的数据库设计

• 节省数据的存储空间
• 保证数据的完整性
• 方便进行数据库应用系统的开发

范式

范式简介

在关系型数据库中，关于数据表设计的基本原则、规则就称为范式。它是一张数据表的设计结构需要满足的某种设计标准的 级别 。要想设计一个结构合理的关系型数据库，必须满足一定的范式。

常用范式

目前关系型数据库有六种常见范式，按照范式级别，从低到高分别是：

• 第一范式（1NF）
• 第二范式 （2NF
• 第三范式（3NF）
• 巴斯-科德范式（BCNF）
• 第四范式(4NF）
• 第五范式（5NF，又称完美范式）

一般来说，在关系型数据库设计中，最高也就遵循到BCNF，普遍还是3NF。但也不绝对，有时候为了提高某些查询性能，还需要破坏范式规则，也就是反规范化。

键和相关属性的概念

范式的定义会使用到主键和候选键，数据库中的键（Key）由一个或者多个属性组成。

数据表中常用的几种键和属性的定义：

• 超键：能唯一标识元组的属性集叫做超键
• 候选键：如果超键不包括多余的属性，那么这个超键就是候选键
• 主键：用户可以从候选键中选择一个作为主键
• 外键：如果数据表R1中的某属性集不是R1的主键，而是另一个数据表R2的主键，那么这个属性集就是数据表R1的外键
• 主属性：包含在任一候选键中的属性称为主属性
• 非主属性：与主属性相对，指的是不包含在任何一个候选键中的属性

通常，我们也将候选键称之为码，把主键也称为主码。因为键可能是由多个属性组成的，针对单个属性，我们还可以用主属性和非主属性来进行区分

小栗子

球员表（player）：球员编号 | 姓名 | 身份证号 | 年龄 | 球队编号

球队表（team） ： 球队编号 | 主教练 | 球队所在地

• 超键 ：对于球员表来说，超键就是包括球员编号或者身份证号的任意组合，比如（球员编号） （球员编号，姓名）（身份证号，年龄）等
• 候选键 ：最小的超键，对于球员表来说，候选键就是（球员编号）或者（身份证号）
• 主键 ：我们自己选定，也就是从候选键中选择一个，比如（球员编号）
• 外键 ：球员表中的球队编号
• 主属性 、 非主属性 ：在球员表中，主属性是（球员编号）（身份证号），其他的属性（姓名） （年龄）（球队编号）都是非主属性

第一范式

第一范式主要是确保数据表中每个字段的值必须具有原子性，数据表中每个字段的值为不可再次拆分的最小数据单元

栗子1

栗子2

第二范式

第二范式要求在满足第一范式的基础上，还要满足数据表里的每一条数据记录都是可唯一标识的。而且所有非主键字段，都必须完全依赖主键，不能只依赖主键的一部分。如果知道主键的所有属性的值，就可以检索到任何元组(行)的任何属性的任何值。

栗子1

成绩表 （学号，课程号，成绩）关系中，（学号，课程号）可以决定成绩，但是学号不能决定成绩，课 程号也不能决定成绩，所以“(学号，课程号)→成绩”就是完全依赖关系

栗子2

比赛表 player_game ，里面包含球员编号、姓名、年龄、比赛编号、比赛时间和比赛场地等属性，这 里候选键和主键都为（球员编号，比赛编号），可以通过候选键（或主键）来决定如下的关系：

(球员编号, 比赛编号) → (姓名, 年龄, 比赛时间, 比赛场地，得分)

但是这个数据表不满足第二范式，因为数据表中的字段之间还存在着如下的对应关系：

(球员编号) → (姓名，年龄)

(比赛编号) → (比赛时间, 比赛场地)

对于非主属性来说，并非完全依赖候选键，会导致：

• 数据冗余 ：如果一个球员可以参加 m 场比赛，那么球员的姓名和年龄就重复了 m-1 次。一个比赛 也可能会有 n 个球员参加，比赛的时间和地点就重复了 n-1 次
• 插入异常 ：如果我们想要添加一场新的比赛，但是这时还没有确定参加的球员都有谁，那么就没法插入
• 删除异常 ：如果我要删除某个球员编号，如果没有单独保存比赛表的话，就会同时把比赛信息删除

• 更新异常 ：如果我们调整了某个比赛的时间，那么数据表中所有这个比赛的时间都需要进行调 整，否则就会出现一场比赛时间不同的情况

  为了避免出现上述的情况，我们可以把球员比赛表设计为下面的三张表。

表名	属性（字段）
球员 player 表	球员编号、姓名和年龄等属性
比赛 game 表	比赛编号、比赛时间和比赛场地等属性
球员比赛关系 player_game 表	球员编号、比赛编号和得分等属性

栗子3

定义了一个名为 Orders 的关系，表示订单和订单行的信息：

违反了第二范式，因为有非主键属性仅依赖于候选键（或主键）的一部分。例如，可以仅通过orderid找 到订单的 orderdate，以及 customerid 和 companyname，而没有必要再去使用productid。

修改，Orders表和OrderDetails表如下，此时符合第二范式。

小结

第二范式要求实体的属性完全依赖主关键字。如果存在不完全依赖，那么这个属性和主的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。

第三范式

第三范式是在第二范式的基础上确保数据表中的每一个非主键字段都和主键字段直接相关，即要求数据表中的所有非主键字段不能依赖于其他非主键字段。(不能存在非主属性A依赖于非主属性B，非主属性B依赖于主键C的情况，即存在”A一B→C”的决定关系）。通俗地讲，该规则的意思是所有非主键属性之间不能有依赖关系，必须相互独立。

栗子1

部门信息表 ：每个部门有部门编号、部门名称、部门简介等信息

员工信息表 ：每个员工有员工编号、姓名、部门编号。列出部门编号后就不能再将部门名称、部门简介 等与部门有关的信息再加入员工信息表中。

如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。

栗子2

栗子3

球员player表 ：球员编号、姓名、球队名称和球队主教练

球员编号决定了球队名称，同时球队名称决定了球队主教练，非主属性球队主教练就会传递依 赖于球员编号，因此不符合 3NF 的要求

如果要达到 3NF 的要求，需要把数据表拆成下面这样：

栗子4

对于范式二中该表做出修改，

此时的Orders关系包含 orderid、orderdate、customerid 和 companyname 属性，主键定义为 orderid。 customerid和companyname均依赖于主键orderid。

例如需要通过orderid主键来查找代表订单中 客户的customerid，同样需要通过 orderid 主键查找订单中客户的公司名称companyname。然而customerid和companyname是存在依赖关系的

小结

关于数据表的设计，有三个范式要遵循：

• 第一范式（1NF），确保每列保持原子性。数据库的每一列都是不可再分的最小数据单元，而不能是集合、数组、记录等非原子数据项
• 第二范式（2NF），确保每列都和主键完全依赖。尤其在复合主键的情况下，非主键部分不应该依赖于部分主键
• 第三范式（3NF）确保每列都和主键列直接相关，而不是间接相关

范式的优点：数据的标准化有助于消除数据库中的数据冗余，第三范式(3NF）通常被认为在性能、扩底性和数据完整性方面达到了最好的平衡。

范式的缺点：范式的使用，可能降低查询的效率。因为范式等级越高，设计出来的数据表就越多、越精细，数据的冗余度就越低，进行数据查询的时候就可能需要关联多张表，这不但代价昂贵，也可能使一些索引策略无效。

反范式化

反范式概述

有时不能简单按照规范要求设计数据表，因为有的数据看似冗余，其实对业务来说十分重要。这时要遵循业务优先的原则，首先满足业务需求，再尽量减少冗余。
如果数据库中的数据量比较大，系统的UV和PV访问频次比较高，则完全按照MySQL的三大范式设计数据表，读数据时会产生大量的关联查询，在一定程度上会影响数据库的读性能。如果想对查询效率进行优化，反范式优化也是一种优化思路。此时可以通过在数据表中增加冗余字段来提高数据库的读性能。

• 为满足某种商业目标 , 数据库性能比规范化数据库更重要
• 在数据规范化的同时 , 要综合考虑数据库的性能
• 通过在给定的表中添加额外的字段，以大量减少需要从中搜索信息所需的时间
• 通过在给定的表中插入计算列，以方便查询

反范式应用

当冗余信息有价值或者能大幅度提高查询效率时才会采取反范式的优化

增加冗余字段的建议

增加冗余字段一定要符合如下两个条件。只有满足这两个条件，才可以考虑增加冗余字段

1. 冗余字段不需要经常进行修改
2. 冗余字段查询时不可或缺

历史快照、历史数据的需要

比如订单中的收货人信息，包括姓名、电话和地址等。每次发生的 订单收货信息 都属于历史快照 ，需要进行保存，但用户可以随时修改自己的信息，这时保存这 些冗余信息是非常有必要的

数据仓库

反范式优化也常用在数据仓库的设计中，因为数据仓库通常存储历史数据，对增删改的实时性要求不 强，对历史数据的分析需求强。这时适当允许数据的冗余度，更方便进行数据分析。

• 数据库设计的目的在于捕获数据，而数据仓库设计的目的在于分析数据
• 数据库对数据的增删改实时性要求强，需要存储在线的用户数据，而数据仓库存储的一般是历史数据
• 数据库设计需要尽量避免冗余，但为了提高查询效率也允许一定的冗余度，而数据仓库在设计上更偏向采用反范式设计

栗子1

员工的信息存储在employees表 中，部门信息存储在departments表 中。通过employees表中的 department_id字段与departments表建立关联关系。如果要查询一个员工所在部门的名称：

SELECT employee_id,department_name
FROM employees e JOIN departments d
ON e.department_id = d.department_id;

如果经常需要进行这个操作，连接查询就会浪费很多时间。可以在 employees表中增加一个冗余字段epartment_name，就不用每次都进行连接操作

栗子2

反范式化的goods商品信息表 设计如下：

栗子3

有 2 个表分别是 商品流水表trans和 商品信息表 goodsinfo。商品流水表里有 400 万条流水记录，商品信息表里有 2000 条商品记录。

反范式问题

• 存储 空间变大

• 一个表中字段做了修改，另一个表中冗余的字段也需要做同步修改，否则 数据不一致

• 若采用存储过程来支持数据的更新、删除等额外操作，如果更新频繁，会非常 消耗系统资源

• 在 数据量小 的情况下，反范式不能体现性能的优势，可能还会让数据库的设计更加 复杂

BCNF

在3NF的基础上提出了巴斯范式，BCNF被认为没有新的设计规范加入，只是对第三范式中设计规范要求更强，使得数据库冗余度更小。BCNF被称为是修正的第三范式，或扩充的第三范式，BCNF不被称为第四范式。

若一个关系达到了第三范式，并且它只有一个候选键，或者它的每个候选键都是单属性，则该关系自然达到BCNF

栗子1

这个表中，一个仓库只有一个管理员，同时一个管理员也只管理一个仓库

依赖关系

仓库名决定管理员，管理员也决定仓库名，同时（仓库名，物品名）的属性集合可以决定数量

• 候选键 ：（管理员，物品名）和（仓库名，物品名），然后从候选键中选择一个作为 主键 ，比 如（仓库名，物品名）
• 主属性 ：包含在任一候选键中的属性（仓库名，管理员和物品名）
• 非主属性 ：数量

符合范式

1. 数据表每个属性都是原子性的，符合 1NF
2. 数据表中非主属性”数量“都与候选键全部依赖，（仓库名，物品名）决定数量，（管理员，物品 名）决定数量，符合 2NF
3. 数据表中的非主属性，不传递依赖于候选键，符合 3NF

存在问题

• 增加一个仓库，但是还没有存放任何物品。根据数据表实体完整性的要求，主键不能有空值，会出现 插入异常
• 如果仓库更换管理员，可能会 修改数据表中的多条记录
• 如果仓库里的商品都卖空，那么此时仓库名称和相应的管理员名称也会随之被删除

解决方案

• 问题原因： 主属性仓库名对于候选键（管理员，物品名）是部分依赖的关系

• 引入BCNF，它在 3NF 的基础上消除了主属性对候选键的部分依 赖或者传递依赖关系

• 如果在关系 $R$ 中，$U$ 为主键，$A$ 属性是主键的一个属性，若存在 $A\rightarrow {Y}$， $Y$ 为主属性，则该关系不属于 BCNF。

根据 BCNF 的要求，需要把仓库管理关系 warehouse_keeper 表拆分如下，这样就不存在主属性对于候选键的部分依赖或传递依赖，数据表的设计就符合 BCNF。

数据表	字段说明
仓库表	（仓库名，管理员）
库存表	（仓库名，物品名，数量）

栗子2

有一个 学生导师表 ，其中包含字段：学生ID，专业，导师，专业GPA，这其中学生ID和专业是联合主键

该表的设计满足三范式，但是存在另一个依赖关系，“专业”依赖于“导师”，每个导师只做一个专业方面的导师，只要知道导师就知道专业，所以部分主键Major依赖于非主键属性Advisor

可以进行以下的调整，拆分成2个表：

学生导师表：

导师表：

第四范式

多值依赖

• 多值依赖即属性之间的一对多关系，记为 $K→→A$
• 函数依赖事实上是单值依赖，所以不能表达属性值之间的一对多关系
• 平凡的多值依赖：全集 $U=K+A$，一个 $K$ 可以对应于多个 $A$，即 $K→→A$。此时整个表就是一组一对多关系
• 非平凡的值依赖：全集 $U=K+A+B$ ，一个 $K$ 可以对应于多个$A$ ，也可以对应于多个 $B$ ，$A$ 与 $B$ 互相独立，即 $K→→A$ ，$K→→B$。整个表有多组一对多关系，且有一部分是相同的属性集合，多部分是互相独立的属性集合

第四范式是在BCNF的基础上消除非平凡且非函数依赖的多值依赖（即把同一表内的多对多关系删除)

栗子

我们建立课程、教师、教材的模型，课程ID，教师ID，教材ID三列作为联合主键 。规定每门课程有对应的一组教师，每门课程也有对应的 一组教材，一门课程使用的教材和教师没有关系。

假如下学期想采用一本新的英版高数教材，但是没确定具体老师来教，那么就无法在这个表中维护Course高数和Book英版高数教材的的关系。

解决办法是把这个多值依赖的表拆解成2个表，分别建立关系

第五范式

第五范式（又称完美范式）和域键范式（DKNF）。 在满足第四范式的基础上，消除不是由候选键所蕴含的连接依赖。如果关系模式R中的每一个连接依赖均由R的候选键所蕴含，则称此关系模式符合第五范式。

函数依赖是多值依赖的一种特殊的情况，而多值依赖实际上是连接依赖的一种特殊情况。但连接依赖不 像函数依赖和多值依赖可以由 语义直接导出 ，而是在 关系连接运算 时才反映出来。存在连接依赖的关系 模式仍可能遇到数据冗余及插入、修改、删除异常等问题。

第五范式处理的是无损连接问题，这个范式基本 没有实际意义 ，因为无损连接很少出现，而且难以察 觉。而域键范式试图定义一个 终极范式 ，该范式考虑所有的依赖和约束类型，但是实用价值也是最小 的，只存在理论研究中

实战演示

1NF

1NF要求所有的字段都是基本数据字段不可进一步拆分。需要确认所有的列中每个字段只包含—种数据。

2NF

2NF要求在满足1NF的基础上满足数据表里的每一条数据记录都是可唯一标识的。而且所有字段都必须完全依赖主键，不能只依赖主键的一部分。

1. 确定表的主键，字段listnumber+barcode可以唯一标识每条记录，因此作为主键

2. 判断完全依赖主键和只依赖部分主键的字段，将依赖主键部分的字段拆分出去，形成新的数据表。进货单明细表里面的goodsname、specification、unit属于商品属性，他们仅依赖于barcode，而不完全依赖主键，因此需要拆分出去，将这三个字段和barcode拆分成新的数据表商品信息表

   

   此外，supplierid、suppliername、stock只依赖于listnumber，而不完全依赖于主键，因此将supplierid、suppliername、stock三个字段和listnumber拆分出去，形成新的数据表进货单头表，剩下的字段组成新的表进货单明细表

   

3. 在商品信息表中，barcode是有可能重复的，比如用户门店可能有散装称重商品和自产商品，会存在条码共用的情况。因此所有字段都不能唯一标识表里的记录，此时必须给表添加主键，如自增字段listnumber。可以将进货单明细表里的barcode都替换为listnumber得到新的进货单明细表

   

此时拆分后的三个表全部满足2NF

3NF

进货单头表中suppliername依赖于supplierid，按照3NF原则将进货单头表拆分成供货商表和新的进货单头表

反范式化

在进货单明细表中quantity*importprice=importvalue，这三个字段可以通过其中任意两个字段计算出来，因此存在冗余字段，解决方案是删除其中一个字段，但对于业务优先原则不一定要这么做。

业务优先原则是指一切以业务需求为主，技术服务于业务。完全按照理论的设计不一定就是最优，还要根据实际情况来决定。

根据业务优先原则，在不影响系统可靠性的前提下，可以保留这三个字段

ER模型

ER模型是一种实体关系模型，是用来描述现实生活中客观存在的事物、事物的属性，以及事物之间关系的一种数据模型。在开发基于数据库的信息系统的设计阶段，通常使用ER模型来描述信息需求和信息特性，帮助我们理清业务逻辑，从而设计出优秀的数据库。

ER 模型要素

• 实体：实体可以看做是数据对象，往往对应于现实生活中的真实存在的个体。在 ER 模型中，用矩形来表 示。实体分为两类，分别是强实体和弱实体。强实体是指不依赖于其他实体的实体；弱实体是指对另 一个实体有很强的依赖关系的实体。
• 属性：属性则是指实体的特性。比如超市的地址、联系电话、员工数等。在 ER 模型中用椭圆形来表示。
• 关系 ：关系则是指实体之间的联系。比如超市把商品卖给顾客，就是一种超市与顾客之间的联系。在 ER 模 型中用菱形来表示。

注意：实体和属性不容易区分。从系统整体的角度出发去看，可以独立存在 的是实体，不可再分的是属性

关系类型

一对一 ：指实体之间的关系是一 一对应的，比如学生和学号的关系属于一对一。

一对多 ：指一边的实体通过关系，可以对应多个另外一边的实体。相反，另外一边的实体通过这个关系，则只能对应唯一的一边的实体。比如一个班级对应多个学生，属于一对多关系

多对多 ：指关系两边的实体都可以通过关系对应多个对方的实体。比如一个选课表，有许多科目，每个科目有很多学生选，而每个学生又可以选择多个科目

电商建模案例

实体

• 地址实体
• 用户实体
• 购物车实体
• 评论实体
• 商品实体
• 商品分类实体
• 订单实体
• 订单详情实体

其中用户和商品分类是强实体，它们不需要依赖其他任何实体。而其他属于弱实体，它们虽然都可以独立存在，但是它们都依赖用户这个实体

关系

• 用户可以在电商平台添加多个地址
• 用户只能拥有一个购物车
• 用户可以生成多个订单
• 用户可以发表多条评论
• 一件商品可以有多条评论
• 每一个商品分类包含多种商品
• 一个订单可以包含多个商品，一个商品可以在多个订单里
• 订单中又包含多个订单详情，因为一个订单中可能包含不同种类的商品

属性

• 地址实体：包括用户编号、省、市、地区、收件人、联系电话、是否是默认地址
• 用户实体：包括用户编号、用户名称、昵称、用户密码、手机号、邮箱、头像、用户级别
• 购物车实体 包括购物车编号、用户编号、商品编号、商品数量、图片文件url
• 订单实体 包括订单编号、收货人、收件人电话、总金额、用户编号、付款方式、送货地址、下单 时间
• 订单详情实体 包括订单详情编号、订单编号、商品名称、商品编号、商品数量
• 商品实体 包括商品编号、价格、商品名称、分类编号、是否销售，规格、颜色
• 评论实体 包括评论id、评论内容、评论时间、用户编号、商品编号
• 商品分类实体 包括类别编号、类别名称、父类别编号

ER模型

ER 模型图转换成数据表

• 一个实体通常转换成一个数据表
• 一个多对多的关系，通常也转换成一个数据表
• 一个1 对 1，或者1 对多的关系，往往通过表的外键来表达，而不是设计一个新的数据表
• 属性转换成表的字段

一个实体转化为数据表

用户实体 转换成用户表

CREATE TABLE `user_info`(
	`id ` BIGINT(20) NOT NULL AUTO_INCREMENT COMMENT '编号',
	`user_name` VARCHAR(200) DEFAULT NULL COMMENT '用户名称',
	`nick_name` VARCHAR(200) DEFAULT NULL COMMENT '用户呢称',
	`passwd` VARCHAR(280) DEFAULT NULL COMMENT '用户密码',
	`phone_num` VARCHAR(200) DEFAULT NULL COMMENT '手机号',
	`email` VARCHAR(200) DEFAULT NULL COMMENT '邮箱',
	`head_img` VARCHAR(200) DEFAULT NULL COMMENT '头像',
	`user_level` VARCHAR(200) DEFAULT NULL COMMENT '用户级别',
	PRIMARY KEY(`id`)
)ENGINE=INNODB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8 COMMENT='用户表';

商品分类实体 转换成商品分类表，由于商品分类有一级分类和二级分类，比如一级分类有家居、手机等等分类，二级分类可以根据手机的一级分类分为手机配件，运营商等，把商品分类实体规划为两张表，分别是一级分类表和二级分类表，之所以这么规划是因为一级分类和二级分类都是有限的，存储为两张表业务结构更加清晰。

-- 一级分类表
CREATE TABLE `base_category1` (
	`id` BIGINT(20) NOT NULL AUTO_INCREMENT COMMENT '编号',
	`name` VARCHAR(10) NOT NULL COMMENT '分类名称',
	PRIMARY KEY (`id`) USING BTREE
)ENGINE=INNODB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC COMMENT='一级分类表';

-- 二级分类表
CREATE TABLE `base_category2` (
	`id` BIGINT(20) NOT NULL AUTO_INCREMENT COMMENT '编号',
	`name` VARCHAR(200) NOT NULL COMMENT '二级分类名称',
	`category1_id`  BIGINT(20) DEFAULT NULL COMMENT '一级分类编号',
	PRIMARY KEY (`id`) USING BTREE
)ENGINE=INNODB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC COMMENT='二级分类表';

如果规划成一张表，则是

CREATE TABLE `base_category`(
	`id` BIGINT(20) NOT NULL  COMMENT '编号',
	`name`  VARCHAR(200) NOT NULL COMMENT '分类名称',
	`category_parent_id` BIGINT(20) DEFAULT NULL COMMENT '父分类编号',
	PRIMARY KEY(`id`) USING BTREE
)ENGINE=INNODB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC COMMENT = '分类表';

如果这样分类的话，那么查询一级分类时就需要判断父分类编号是否为空，但是如果插入二级分类时也是空就容易造成业务数据混乱。而且查询二级分类时IS NOT NULL条件是无法使用到索引的。同时这样的设计也不符合第二范式（因为父分类编号并不依赖分类编号ID，因为父分类编号可以有很多数据为NULL），所以需要进行表的拆分。因此无论是业务需求还是数据库表的规范来看都应该拆分为两张表。

地址实体 转换成地址表

CREATE TABLE `user_address` (
	`id` BIGINT(20) NOT NULL AUTO_INCREMENT COMMENT '编号',
	`province` VARCHAR(500) DEFAULT NULL COMMENT '省',
	`city` VARCHAR(500) DEFAULT NULL COMMENT '市',
	`user_address` VARCHAR(500) DEFAULT NULL COMMENT '具体地址',
	`user_id` BIGINT(20) DEFAULT NULL COMMENT '用户id',
	`consignee` VARCHAR(40) DEFAULT NULL COMMENT '收件人',
	`phone_num` VARCHAR(40) DEFAULT NULL COMMENT '联系方式',
	`is_default` VARCHAR(1) DEFAULT NULL COMMENT '是否是默认',
	PRIMARY KEY(`id`)
) ENGINE=INNODB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='用户地址表';

订单实体 转换成订单表

CREATE TABLE `order_info`(
	`id` BIGINT(20) NOT NULL AUTO_INCREMENT COMMENT '编号',
	`consignee` VARCHAR(100) DEFAULT NULL CONMENT '收货人',
	`consignee_tel` VARCHAR(20) DEFAULT NULL COMMENT '收件人电话',
	`total_amount` DECIMAL(10,2) DEFAULT NULL COMMENT '总金额',
	`user_id` BIGINT(20) DEFAULT NULL COMMENT '用户id',
	`payment_way` VARCHAR(20) DEFAULT NULL COMMENT '付款方式',
	`delivery_address` VARCHAR(1000) DEFAULT NULL COMMENT '送货地址',
	`create_time` DATETIME DEFAULT NULL COMMENT '下单时间',
	PRIMARY KEY(`id`) USING BTREE
)ENGINE=INNODB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC COMMENT='订单表';

订单详情实体 转换成订单详情表

CREATE TABLE `order_detail`(
	`id` BIGINT(20) NOT NULL AUTO_INCREMENT COMMENT '订单详情编号',
	`order_id` BIGINT(20) DEFAULT NULL COMMENT '订单编号',
	`sku_id` BIGINT(20) DEFAULT NULL COMMENT 'sku_id',
	`sku_name` VARCHAR(200) DEFAULT NULL COMMENT 'sku名称',
	`sku_num` VARCHAR(200) DEFAULT NULL COMMENT '购买个数',
	`create_time` DATETIME DEFAULT NULL COMMENT '操作时间',
	PRIMARY KEY(`id`) USING BTREE
)ENGINE=INNODB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC COMMENT= '订单详情表';

购物车实体 转换成购物车表

CREATE TABLE `cart_info`(
	`cart_id` BIGINT(20) NOT NULL AUTO_INCREMENT COMMENT '编号',
	`user_id` VARCHAR(200) DEFAULT NULL COMMENT '用户id',
	`sku_id` BIGINT(20) DEFAULT NULL COMMENT 'skuid',
	`sku_num` INT(11) DEFAULT NULL COMMENT '数量',
	`img_url` VARCHAR(500) DEFAULT NULL COMMENT '图片文件',
	PRIMARY KEY(`id`) USING BTREE
)ENGINE=INNODB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC COMMENT='购物车表';

评论实体 转换成评论表

CREATE TABLE `sku_comments` (
	`comment_id` BIGINT(20) NOT NULL AUTO_INCREMENT COMMENT '评论编号',
	`user_id ` BIGINT(20) DEFAULT NULL COMMENT '用户编号',
	`sku_id` DECIMAL(18,0) DEFAULT NULL COMMENT '商品编号',
	`comment` VARCHAR(2000) DEFAULT NULL COMMENT '评论内容',
	`create_time` DATETIME DEFAULT NULL COMMENT '评论时间',
	PRIMARY KEY(`id`) USING BTREE
) ENGINE=INNODB AUTO_INCREMENT=45 DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC COMMENT='商品评论表';

商品实体 转化成商品表

CREATE TABLE `sku_info` (
	`sku_id` BIGINT(20) NOT NULL AUTO_INCREMENT COMMENT '商品编号(itemID)',
	`price` DECIMAL(10,0) DEFAULT NULL COMMENT '价格',
	`sku_name` VARCHAR(200) DEFAULT NULL COMMENT 'sku名称',
	`sku_desc` VARCHAR(2000) DEFAULT NULL COMMENT '商品规格描述',
	`category3_id` BIGINT(20) DEFAULT NULL COMMENT '三级分类id(冗余）',
	`color` VARCHAR(2000) DEFAULT NULL COMMENT '颜色',
	`is_sale` TINYINT(3) NOT NULL DEFAULT '0' CONMENT '是否销售(1:是 0:否)',
	PRIMARY KEY(`id`) USING BTREE
) ENGINE=INNODB AUTO_INCREMENT=45 DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC COMMENT='商品表';

一个多对多关系转成数据表

这个ER模型中的多对多的关系有1个，即商品和订单之间的关系，同品类的商品可以出现在不同的订单中，不同的订单也可以包含同一类型的商品，所以它们之间的关系是多对多。针对这种情况需要设计一个独立的表来表示，这种表一般称为中间表。
可以设计一个独立的订单详情表，来代表商品和订单之间的包含关系。这个表关联到z个实体，分别是订单、商品。所以，表中必须要包括这2个实体转换成的表的主键。除此之外，还要包括该关系自有的属性：商品数量，商品下单价格以及商品名称。

CREATE TABLE `order_detail`(
	`id` BIGINT(20) NOT NULL AUTO_INCREMENT COMMENT '订单详情编号',
	`order_id` BIGINT(20) DEFAULT NULL COMMENT '订单编号',
	`sku_id` BIGINT(20) DEFAULT NULL COMMENT 'sku_id',
	`sku_name` VARCHAR(200) DEFAULT NULL COMMENT 'sku名称',
	`sku_num` VARCHAR(200) DEFAULT NULL COMMENT '购买个数',
	`create_time` DATETIME DEFAULT NULL COMMENT '操作时间',
	PRIMARY KEY(`id`) USING BTREE
)ENGINE=INNODB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC COMMENT= '订单详情表';

通过外键来表达一对多关系

在上面的表的设计中，可以用外键来表达1对多的关系。比如在商品评论表sku_comments中，分别把user_id、sku_id定义成外键，以使用下面的语句设置外键。

CONSTRAINT fk_comment_user FOREIGN KEY (user_id) REFERENCES user_info (id),

CONSTRAINT fk_comment_sku FORETGN KEY (sku_id) REFERENCES sku_info (sku_id)

外键约束主要是在数据库层面上保证数据的一致性，但是因为插入和更新数据需要检查外键，理论上性能会有所下降，对性能是负面的影响。

实际的项目，不建议使用外键，一方面是降低开发的复杂度（有外键的话主从表类的操作必须先操作主表），另外是有外键在处理数据的时候非常麻烦。在电商平台，由于并发业务量比较大，所以一般不设置外键，以免影响数据库性能。
在应用层面做数据的一致性检查，本来就是一个正常的功能需求。如学生选课的场景，课程肯定不是输入的，而是通过下拉或查找等方式从系统中进行选取，就能够保证是合法的课程ID，因此就不需要靠数据库的外键来检查

把属性转换成表的字段

商品属性转化成商品信息表中的字段

CREATE TABLE `sku_info` (
	`sku_id` BIGINT(20) NOT NULL AUTO_INCREMENT COMMENT '商品编号(itemID)',
	`price` DECIMAL(10,0) DEFAULT NULL COMMENT '价格',
	`sku_name` VARCHAR(200) DEFAULT NULL COMMENT 'sku名称',
	`sku_desc` VARCHAR(2000) DEFAULT NULL COMMENT '商品规格描述',
	`category3_id` BIGINT(20) DEFAULT NULL COMMENT '三级分类id(冗余）',
	`color` VARCHAR(2000) DEFAULT NULL COMMENT '颜色',
	`is_sale` TINYINT(3) NOT NULL DEFAULT '0' CONMENT '是否销售(1:是 0:否)',
	PRIMARY KEY(`id`) USING BTREE
) ENGINE=INNODB AUTO_INCREMENT=45 DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC COMMENT='商品表';

数据表的设计原则

数据表的个数越少越好

RDBMS的核心在于E-R图，数据表越少，证明实体和联系设计得越简洁，既方便理解又方便操作。

数据表中的字段个数越少越好

字段个数越多，数据冗余的可能性越大。设置字段个数少的前提是各个字段相互独立，而不是某个字段的取值可以由其他字段计算出来。当然字段个数少是相对的，通常会在数据冗余和检索效率中进行平衡。

数据表中联合主键的字段个数越少越好

设置主键是为了确定唯一性，当一个字段无法确定唯一性时就需要采用联合主键的方式（用多个字段来定义一个主键）。联合主键中的字段越多，占用的索引空间越大，不仅会加大理解难度，还会增加运行时间和索引空间，因此联合主键的字段个数越少越好。

使用主键和外键越多越好

数据库的设计实际上就是定义各种表，以及各种字段之间的关系。这些关系越多，证明这些实体之间的冗余度越低，利用度越高。这样做的好处在于不仅保证了数据表之间的独立性，还能提升相互之间的关联使用率。

数据库对象编写建议

关于库

• 【强制】库的名称必须控制在32个字符以内，只能使用英文字母、数字和下划线，建议以英文字 母开头
• 【强制】库名中英文 一律小写 ，不同单词采用 下划线 分割。须见名知意
• 【强制】库的名称格式：业务系统名称_子系统名
• 【强制】库名禁止使用关键字（如type,order等）
• 【强制】创建数据库时必须显式指定字符集，并且字符集只能是utf8或者utf8mb4
• 【建议】对于程序连接数据库账号，遵循 权限最小原则使用数据库账号只能在一个DB下使用，不准跨库。程序使用的账号 原则上不准有drop权限
• 【建议】临时库以tmp_为前缀，并以日期为后缀； 备份库以 bak_为前缀，并以日期为后缀

关于表、列

• 【强制】表和列的名称必须控制在32个字符以内，表名只能使用英文字母、数字和下划线，建议以英文字母开头
• 【强制】 表名、列名一律小写 ，不同单词采用下划线分割。须见名知意。
• 【强制】表名要求有模块名强相关，同一模块的表名尽量使用统一前缀
• 【强制】创建表时必须显式指定字符集为utf8或utf8mb4
• 【强制】表名、列名禁止使用关键字（如type,order等）
• 【强制】创建表时必须显式指定表存储引擎类型。如无特殊需求，一律为InnoDB
• 【强制】建表必须有comment
• 【强制】字段命名应尽可能使用表达实际含义的英文单词或缩写
• 【强制】布尔值类型的字段命名为is_描述 。如member表上表示是否为enabled的会员的字段命 名为is_enabled
• 【强制】禁止在数据库中存储图片、文件等大的二进制数据 通常文件很大，短时间内造成数据量快速增长，数据库进行数据库读取时，通常会进行大量的随 机IO操作，文件很大时，IO操作很耗时。通常存储于文件服务器，数据库只存储文件地址信息
• 【建议】建表时关于主键： 表必须有主键
  • 强制要求主键为id，类型为int或bigint，且为 auto_increment 建议使用unsigned无符号型
  • 标识表里每一行主体的字段不要设为主键，建议 设为其他字段如user_id，order_id等，并建立unique key索引。因为如果设为主键且主键值为随机 插入，则会导致innodb内部页分裂和大量随机I/O，性能下降
• 【建议】核心表（如用户表）必须有行数据的创建时间字段 （create_time）和最后更新时间字段（update_time），便于查问题
• 【建议】表中所有字段尽量都是NOT NULL属性，业务可以根据需要定义 DEFAULT值 。 因为使用 NULL值会存在每一行都会占用额外存储空间、数据迁移容易出错、聚合函数计算结果偏差等问题
• 【建议】所有存储相同数据的列名和列类型必须一致 （一般作为关联列，如果查询时关联列类型 不一致会自动进行数据类型隐式转换，会造成列上的索引失效，导致查询效率降低）
• 【建议】中间表（或临时表）用于保留中间结果集，名称以tmp_开头。 备份表用于备份或抓取源表快照，名称以bak_开头。中间表和备份表定期清理
• 【建议】创建表时可以使用可视化工具。这样可以确保表、字段相关的约定都能设置上

CREATE TABLE user_info (
  `id` INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '自增主键',
  `user_id` BIGINT (11) NOT NULL COMMENT '用户id',
  `username` VARCHAR (45) NOT NULL COMMENT '真实姓名',
  `email` VARCHAR (30) NOT NULL COMMENT '用户邮箱',
  `nickname` VARCHAR (45) NOT NULL COMMENT '昵称',
  `birthday` DATE NOT NULL COMMENT '生日',
  `sex` TINYINT (4) DEFAULT '0' COMMENT '性别',
  `short_introduce` VARCHAR (150) DEFAULT NULL COMMENT '一句话介绍自己，最多50个汉字',
  `user_resume` VARCHAR (300) NOT NULL COMMENT '用户提交的简历存放地址',
  `user_register_ip` INT NOT NULL COMMENT '用户注册时的源ip',
  `create_time` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `update_time` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '修改时间',
  `user_review_status` TINYINT NOT NULL COMMENT '用户资料审核状态，1为通过，2为审核中，3为未通过，4为还未提交审核',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uniq_user_id` (`user_id`),
  KEY `idx_username` (`username`),
  KEY `idx_create_time_status` (`create_time`,`user_review_status`)
) ENGINE = INNODB DEFAULT CHARSET = utf8 COMMENT = '网站用户基本信息';

关于索引

• 【强制】InnoDB表必须主键为id int/bigint auto_increment，且主键值禁止被更新
• 【强制】InnoDB和MyISAM存储引擎表，索引类型必须为BTREE
• 【建议】主键的名称以pk_开头，唯一键以uni_或uk_开头，普通索引以idx_开头，一律使用小写格式，以字段的名称或缩写作为后缀
• 【建议】多单词组成的columnname，取前几个单词首字母，加末单词组成column_name。如: sample 表 member_id 上的索引：idx_sample_mid
• 【建议】单个表上的索引个数不能超过6个
• 【建议】在建立索引时，多考虑建立联合索引，并把区分度最高的字段放在最前面
• 【建议】在多表 JOIN 的SQL里，保证被驱动表的连接列上有索引，这样JOIN 执行效率最高
• 【建议】建表或加索引时，保证表里互相不存在冗余索引 。 比如：如果表里已经存在key(a,b)， 则key(a)为冗余索引，需要删除

SQL编写

• 【强制】程序端SELECT语句必须指定具体字段名称，禁止写成 *
• 【建议】程序端insert语句指定具体字段名称，不要写成INSERT INTO t1 VALUES(…)
• 【建议】除静态表或小表（100行以内），DML语句必须有WHERE条件，且使用索引查找
• 【建议】INSERT INTO…VALUES(XX),(XX),(XX).. 这里XX的值不要超过5000个。 值过多虽然上线很快，但会引起主从同步延迟
• 【建议】SELECT语句不要使用UNION，推荐使用UNION ALL，并且UNION子句个数限制在5个以 内
• 【建议】线上环境，多表 JOIN 不要超过5个表
• 【建议】减少使用ORDER BY，和业务沟通能不排序就不排序，或将排序放到程序端去做。ORDER BY、GROUP BY、DISTINCT 这些语句较为耗费CPU，数据库的CPU资源是极其宝贵的
• 【建议】包含了ORDER BY、GROUP BY、DISTINCT 这些查询的语句，WHERE 条件过滤出来的结果集请保持在1000行以内，否则SQL会很慢
• 【建议】对单表的多次alter操作必须合并为一次 对于超过100W行的大表进行alter table，必须经过DBA审核，并在业务低峰期执行，多个alter需整 合在一起。 因为alter table会产生表锁，期间阻塞对于该表的所有写入，对于业务可能会产生极 大影响
• 【建议】批量操作数据时，需要控制事务处理间隔时间，进行必要的sleep
• 【建议】事务里包含SQL不超过5个。 因为过长的事务会导致锁数据较久，MySQL内部缓存、连接消耗过多等问题
• 【建议】事务里更新语句尽量基于主键或UNIQUE KEY， 否则会产生间隙锁，内部扩大锁定范围，导致系统性能下降，产生死锁