数据库设计规范[掌握好规范，设计出的表一般不会差]-编程知识

数据库设计
命名规范
数据库表名、字段名、索引名等都要命名规范，可读性高（一般要求用英文），让别人一看命名，就知道这个字段表示什么意思
user_name, user_age
表名，字段名必须使用小写字母或者数字，禁止使用数字开头，主键索引名为pk_字段名，唯一索引名为uk_ 字段名，普通索引名则为idx_字段名

字段类型

设计表时，我们需要选择合适的字段类型，比如：

尽可能选择存储空间小的字段类型，就好像数字类型的，从tinyint,smallint,int,bigint从左往右开始选择
小数类型如金额，则选择decimal,禁止使用float 和double
varchar是可变长字符串，不予先分配存储空间，长度不要超过5000
如果存储的值太大，建议字段类型修改为text,同时抽出单独一张表，用主键与之对应
同一表中，所有varchar字段的长度加起来，不能大于65535,如果有这样的需求，请使用text/longtext类型

主键设计的话，最好不要与业务逻辑有所关联，有些业务上的字段，比如身份证，虽然是唯一的，一些开发者喜欢用它来做主键，但是不是很建议。主键最好是毫无意义的一串独立不重复的数字，比如uuid，又比如auto_increment自增的主键，或者是雪花算法生成的主键等等

选择合适的字段长度

数据库字段长度表示字符长度还是字节长度？

其实在mysql中，varchar和char类型的表示字符长度，而其他类型的表示的长度是都表示字节长度，比如char(10)表示的字符长度是10，而bigint(4)表示显示长度是4个字节，但是因为bigint实际长度是8个字节，所以bigint(4)的实际长度就是8个字节

字段高度一般为2的幂哈 username varchar(32)

优先考虑逻辑删除而不是物理删除

什么是物理删除？什么是逻辑删除？

物理删除：把数据从硬盘中删除，可释放存储空间

逻辑删除：给数据添加一个字段，比如is_deleted，以标记该数据已经逻辑删除

物理删除就是执行delete语句

逻辑删除就是这样：

update t_user set is_deleted = 1 where user_id = '666'

每个表都需要添加几个通用字段

如主键，create_time,modifed_time等

表必备一般来说，或具备这几个字段

id:主键，一个表必须得有主键，必须

create_time:创建时间，必须

modifed_time:修改时间，必须，更新记录时，需要更新他

version:数据记录的版本号，用于乐观锁，非必须

remark：数据记录备注：非必须

modified_by:修改人：非必须

creator:创建人：非必须

一个表的字段不宜过多

我们建表的时候，要牢记，一张表的字段不宜过多哈，一般尽量不要超过20个字段，笔者记得上个公司，有伙伴设计开户表，加了五十多个字段

如果一个表的字段过多，表中保存的数据可能就会很大，查询效率就会很低，因此。一张表不要涉及太多字段，如果业务需求，实在需要很多字段，可以把一张大的表，拆分成多张小的表，他们的主键相同即可

当表的字段数非常多时，可以将表分成两张表，一张作为条件查询表，一张作为详细内容表

尽可能使用not null定义字段

如果没有特殊的理由，一般都建议将字段定义为not null

为什么呢？

首先， notnull 可以防止出现空指针问题
其次，null值存储也需要额外的空间的，他也会导致比较运算比较复杂，使优化器难以优化SQL
NULL值有可能会导致索引失效
如果将字段默认设置为一个空字符串或常量值并没有什么不同，且都不会影响到应用逻辑，那就可以将字段设置为not null

设计表时，评估那些字段需要加索引

首先，评估你的表数据量，如果你的表数据量只有一百几十行，就没必要加索引，否则设计表的时候，如果有查询条件的字段，一般就需要建立索引，但是索引也不能滥用

索引也不要建立的太多，一般单表索引个数不要超过五个，因为创建过多的索引，会降低写的速度
区分度不高的字段，不能加索引，如性别等
索引创建完后，还是要注意避免索引失效的情况，如使用mysql内置函数，会导致索引失效的
索引过多的话，可以通过联合索引的方式来优化，然后的话，索引还有一些规则，如覆盖索引，最左匹配原则、

假设你新建一张用户表，如下

create Table t_user(    'id' int(11) not null auto_increment,'user_id' int(11) not null,'age' int(11) default null,'name' varchar(255) not  null,'create_time' datetime not null,'modified_time' datetime not null,primary key('id')
)engine = InnoDB DEFAULT CHARSET = utf-8

对于这张表，很可能会有根据user_id或者name查询用户信息，并且，user_id是唯一的。因此，你是可以给user_id加上唯一索引，name加上普通索引

create Table t_user(    'id' int(11) not null auto_increment,'user_id' int(11) not null,'age' int(11) default null,'name' varchar(255) not  null,'create_time' datetime not null,'modified_time' datetime not null,primary key('id'),key 'idx_name' ('name') using btree,unique key un_user_id (user_id)
)engine = InnoDB DEFAULT CHARSET = utf-8

不需要严格遵守3nf，通过业务字段冗余来减少表关联

什么数据库三范式(3NF),大家是否还有印象？

第一范式：对属性的原子性，要求属性具有原子性，不可再分解

第二范式：对记录的唯一性，要求记录有唯一标识，及实体的唯一性，即不存在部分依赖

第三范式：对字段的冗余性，要求任何字段不能由其他字段派生出来，他要求字段没有冗余，即不存在传递依赖

我们设计表及其字段之间的关系，应尽量满足第三范式，但是有时候，可以适当冗余，来提高效率，比如如下张表

商品名称	商品型号	单价	数量	总金额
手机	华为	8000	5	40000

以上这张表存放商品信息的基本表，总金额这个字段的存在，表明该表的设计不满足第三范式，因为总金额可以由单价*数量得到，说明总金额是冗余字段，但是，增加总金额这个冗余字段，可以提高查询统计速度，这就是以空间换时间的方法。

当然这只是一个小例子，大家开发设计的时候，要结合具体业务！

避免使用mysql保留字

如果库名，表名，字段名等属性含有保留字时，sql语句必须用反引号来引用属性名称，这将使得SQL语句书写，shell脚本中变量的转义等变的非常复杂

因此，我们一般避免使用mysql保留字，如select，interval,desc等

不搞外键关联，一般都在代码维护

什么是外键呢？

外键，也叫foreign key，他是用于将两个表连接在一起的键。foreign key是一个表中的字段（或字段集合），他引用另一个表中的primary key，他是用来表征数据的一致性和完整性的

阿里的java规范也有这么一条

不得使用外，一切外键概念必须在应用层解决

我们为什么不推荐使用外键呢

使用外键存在性能问题，并发死锁问题，使用起来不方便等等。每次做DELETE或者UPDATE都必须考虑外键约束，会导致开发的时候很难受，测试数据造数据也不方便
还有一个场景不能使用外键，就是分库分表

一般都选择INNOD存储引擎

建表是需要选择存储引擎的，我们一般都选择INNODB存储引擎，除非读写比率小于1%，才考虑使用MyISAM

有些小伙伴可能会有疑惑，不是还有MEMORY等其他存储引擎吗？什么时候使用它呢？其实其他存储引擎一般除了都建议在DBA的指导下使用。

我们来复习一下这MySQL这三种存储引擎的对比区别吧：

特性	INNODB	MyISAM	MEMORY
事务安全	支持	无	无
存储限制	64TB	有	有
空间使用	高	低	低
内存使用	高	低	高
插入数据速度	低	高	高
是否支持外键	支持	无	无

选择合适统一的字符集。

数据库库、表、开发程序等都需要统一字符集，通常中英文环境用utf8。

MySQL支持的字符集有utf8、utf8mb4、GBK、latin1等。

utf8：支持中英文混合场景，国际通过，3个字节长度
utf8mb4: 完全兼容utf8，4个字节长度，一般存储emoji表情需要用到它。
GBK ：支持中文，但是不支持国际通用字符集，2个字节长度
latin1：MySQL默认字符集，1个字节长度

如果你的数据库字段是枚举类型的，需要在comment注释清楚

如果你设计的数据库字段是枚举类型的话，就需要在comment后面注释清楚每个枚举的意思，以便于维护

正例如下：

`session_status` varchar(2) COLLATE utf8_bin NOT NULL COMMENT 'session授权态 00：在线-授权态有效 01：下线-授权态失效 02：下线-主动退出 03：下线-在别处被登录'

反例：

`session_status` varchar(2) COLLATE utf8_bin NOT NULL COMMENT 'session授权态'

时间的类型选择

我们设计表的时候，一般都需要加通用时间的字段，如create_time、modified_time等等。那对于时间的类型，我们该如何选择呢？

对于MySQL来说，主要有date、datetime、time、timestamp 和 year。

date ：表示的日期值, 格式yyyy-mm-dd,范围1000-01-01 到 9999-12-31，3字节
time ：表示的时间值，格式 hh:mm:ss，范围-838:59:59 到 838:59:59，3字节
datetime：表示的日期时间值，格式yyyy-mm-dd hh:mm:ss，范围1000-01-01 00:00:00到9999-12-31 23:59:59```,8字节，跟时区无关
timestamp：表示的时间戳值，格式为yyyymmddhhmmss，范围1970-01-01 00:00:01到2038-01-19 03:14:07，4字节，跟时区有关
year：年份值，格式为yyyy。范围1901到2155，1字节

推荐优先使用datetime类型来保存日期和时间，因为存储范围更大，且跟时区无关。