数据库规范——学习小记
之前在学习后端开发的时候，在数据库这一块，有关建表与查询效率等方面一直存有疑问，但因为做的项目都很小，不太需要考虑效率与规范，所以想着能实现功能就行。因此最近打算深入了解一些建表的规范以及如何提高查询效率。
表设计规范
命名规范的话，之前倒是都有注意，大致总结为以下几点：
表命名
- 表名前应该加上前缀，表的前缀一个用系统或模块的英文名称缩写，然后驼峰式命名
- 表名应该有意义，易于理解，最好使用可以表达功能的英文单词或缩写，如果用英文单词表示，建议使用完整的英文单词
- 表名最好不要超过3个英文单词长度
- 在数据库表命名时应该用英文单词的单数形式
- 如果是后台表命名时应该在表名基础上加上后缀_b（这个之前倒是没有注意过
- 在表创建完成前，应该为表添加表的注释。
表字段命名：
- 数据库表字段应该是有意义而且易于理解的，最好是能够表达字段含义的英文字母
- 系统中所有属于内码，即仅用于标识唯一性和程序内部用到的标识性字段，字段名称建议取为 ID ，采用类型为整型或长整型.
- 系统中属于是业务内的编号字段，代表一定业务信息，建议字段命名为code , 如工作单编号wf_code .（这个之前好像比较少了解，学习了
- 不要在数据库表字段中包含数据类型，如：datetime
- 不要在数据库表字段命名时重复表名，可以使用表名首字母（不包含数据库表名前缀）
PS：在数据库表字段命名时；不建议使用数据库关键字,如：name,time ,datetime password 等
表设计规范
- 除了timestamp、datetime、image等类型之外，数据类型应该有默认值，如字符型为一个空字符，数值型为0，逻辑型为0，这也是我之前没有注意过的细节
- 字段的设计上尽量符合三大范式（下文会提到）
表索引
这一块我之前很少了解，这里着重总结一下。参考了深入浅出数据库索引原理这篇博客，讲的比较形象。
如何创建索引
创建索引是很简单的，有如下语法
CREATE [UNIQUE|FULLTEXT|SPATIAL] INDEX index_name [USING index_type] ON table_name (index_col_name,...)
如果不指定索引类型，则默认是普通索引。[]内为可选项。以及删除索引的操作如下
DROP INDEX index_name ON talbe_name
ALTER TABLE table_name DROP INDEX index_name
上下两条语句是等价的。
何时使用索引
添加索引的目的是为了提高查询效率，但并不是无脑添加的，不恰当的添加索引还可能降低效率。在这方面参考了这篇博客Mysql创建索引。简单来说，添加索引有以下一些建议：对常用于条件查询的字段，查询中排序的字段，查询中与其他表关联的字段添加索引。对于记录数较少的表，需要频繁插入、更改的表不建议建立索引。因为索引本身也要占据空间，以及每次修改操作需要修改索引，有一定时间开销。
数据库的三大范式
这个地方参考了数据库的三大范式和五大约束、数据库设计三大范式等博客文章
-
第一范式（1NF）：数据表中的每一列(字段)，必须是不可拆分的最小单元，也就是确保每一列的原子性。
-
第二范式（2NF）：满足1NF后要求表中的所有列，都必需依赖于主键，而不能有 任何一列与主键没有关系（一个表只描述一件事情）。否则就需要拆成两张表。
-
第三范式（3NF）：满足2NF后，要求：表中的每一列都要与主键直接相关，而不是间接相关（表中的每一列只能依赖于主键）。这里可能不太好理解，举个例子：订单表中需要有客户相关信息，在分离出客户表之后，订单表中只需要有一个用户ID即可，而不能有其他的客户信息，因为其他的用户信息是直接关联于用户ID，而不是关联于订单ID。
以上的定义讲的比较书面，简单地可以这样总结：
①第1范式：每个表中列都是不可拆分的最小单元
②第2范式：一张表只描述一件事情，即所有列都与主键有关
③第3范式：用外键做表的关联，除此之外不要储存其他表的信息
原则上数据库的设计要遵守以上三大范式，但这只是一般设计数据库的基本理念，可以建立冗余较小、结构合理的数据库。如果有特殊情况，当然要特殊对待，数据库设计最重要的是看需求跟性能，需求>性能>表结构。所以不能一味的去追求范式建立数据库。
总结收获
比较针对地对数据库的使用进行了一次粗略学习，了解了一些数据库的规范和特点。不过对于目前而言，在项目用户量较小的情况下，这些用于提高效率或减少冗余的知识可能用处不大，但尽早了解总是有益的。