数据库设计规范(笔记)

数据库设计规范-范式

第一范式（1NF）
第二范式（2NF）
第三范式（3NF）
巴德斯科范式（BCNF）
第四范式（4NF）
第五范式（5NF）

1. 第一范式 1NF

属于第一范式关系的所有属性都不可再分，即数据项不可分。
(1NF是所有关系型数据库的最基本要求)

2. 第二范式（2NF）

若某关系R属于第一范式，且每一个非主属性完全函数依赖于任何一个候选码，则关系R属于第二范式。

换个说法，第二范式是指每个表必须有一个（有且仅有一个）数据项作为关键字或主键（primary key），其他数据项与关键字或者主键一一对应，即其他数据项完全依赖于关键字或主键。由此可知单主属性的关系均属于第二范式。

判断一个关系是否属于第二范式：

• 找出数据表中的所有码；
• 找出所有主属性和非主属性；
• 判断所有的非主属性对码的部分函数依赖。

3. 第三范式 3NF

非主属性既不传递依赖于码，也不部分依赖于码。

数据库设计规范-mysql设计建议

库设计规范：

• 库的名称必须控制在32个字符以内，相关模块的表名与表名之间尽量提现join的关系
• 库的名称格式：业务系统名称_子系统名，同一模块使用的表名尽量使用统一前缀。
• 创建数据库时必须显式指定字符集，并且字符集只能是utf8或者utf8mb4。创建数据库SQL举例：create database db1 default character set utf8;

表设计规范：

• 表和列的名称必须控制在32个字符以内，表名只能使用字母、数字和下划线，一律小写。
• 表名要求模块名强相关，如师资系统采用”sz”作为前缀，渠道系统采用”qd”作为前缀等。
• 创建表时必须显式指定字符集为utf8或utf8mb4。
• 创建表时必须显式指定表存储引擎类型，如无特殊需求，一律为InnoDB。因为Innodb表支持事务、行锁、宕机恢复、MVCC等关系型数据库重要特性，为业界使用最多的MySQL存储引擎。而这是其他大多数存储引擎不具备的，因此首推InnoDB。
• 建表必须有comment
• 建表时关于主键：(1)强制要求主键为id，类型为int或bigint，且为auto_increment；(2)标识表里每一行主体的字段不要设为主键，建议设为其他字段如user_id，order_id等，并建立unique key索引。因为如果设为主键且主键值为随机插入，则会导致innodb内部page分裂和大量随机I/O，性能下降。
• 表中所有字段必须都是NOT NULL属性，业务可以根据需要定义DEFAULT值。因为使用NULL值会存在每一行都会占用额外存储空间、数据迁移容易出错、聚合函数计算结果偏差等问题。
• 建议对表里的blob、text等大字段，垂直拆分到其他表里，仅在需要读这些对象的时候才去select。
• 反范式设计：把经常需要join查询的字段，在其他表里冗余一份。如user_name属性在user_account，user_login_log等表里冗余一份，减少join查询。

字段数据类型设计规范：

• 表中的自增列（auto_increment属性），推荐使用bigint类型。因为无符号int存储范围为-2147483648~2147483647（大约21亿左右），溢出后会导致报错。
• 业务中选择性很少的状态status、类型type等字段推荐使用tinytint或者smallint类型节省存储空间。
• 业务中IP地址字段推荐使用int类型，不推荐用char(15)。因为int只占4字节，可以用如下函数相互转换，而char(15)占用至少15字节。
• 不推荐使用enum，set。 因为它们浪费空间，且枚举值写死了，变更不方便。推荐使用tinyint或smallint。
• 存储金钱的字段，建议用int，程序端乘以100和除以100进行存取。因为int占用4字节，而double占用8字节，空间浪费。
• 文本数据尽量用varchar存储。
• 时间类型尽量选取timestamp。

索引设计规范-三星索引

三星索引是指导我们创建一个优秀索引的一个思想，它指的是我们在设计索引时遵守的三个原则，分别为：

• 第一颗星需要取出所有等值谓词中的列，作为索引开头的最开始的列（任意顺序）；
• 第二颗星需要将 ORDER BY 列加入索引中；
• 第三颗星需要将查询语句剩余的列全部加入到索引中；

一般来说，三星索引对于一个查询语句来说是最好的索引。

设计规范不是死的，必须根据具体业务做出相应的合理设计，有时，妥协也是必须的。