浅谈数据库设计

数据库设计是每个程序员将来发展都要做的事情，那么我们话不多说先怼三范式。

三范式

背景

提出是数据库设计三范式的时间是上个世纪70年代，科技和现在比差了50年，内存也很紧缺，所以要提出一系列规范来限制数据库，使数据冗余尽量小。

目的

规范化目的是使结构更合理，消除存储异常，使数据冗余尽量小。便于插入、删除和更新。

遵从概念单一化“一事一地”原则，即一个关系模式描述一个实体或实体间的一种联系。规范的实质就是概念的单一化。

一个关系模式接着分解可以得到不同关系模式集合，也就是说分解方法不是惟一的。最小冗余的要求必须以分解后的数据库能够表达原来数据库所有信息为前提来实现。其根本目标是节省存储空问，避免数据不一致性，提高对关系的操作效率，同时满足应用需求。实际上，并不一定要求全部模式都达到BCNF不可。有时故意保留部分冗余可能更方便数据查询。尤其对于那些更新频度不高，查询频度极高的数据库系统更是如此。

内容

第一范式（1NF）即确保每列保持原子性

是指在关系模型中，对于添加的一个规范要求，所有的域都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。即实体中的某个属性有多个值时，必须拆分为不同的属性。在符合第一范式（1NF）表中的每个域值只能是实体的一个属性或一个属性的一部分。简而言之，第一范式就是无重复的域。

原子是保持物质化学性质的最小微粒，所以每列原子性质就是列不可再分，

例如  订单   购买5个100块钱的娃娃，数量是5个，单价是100元/个，那么总价是500元。总价就可以拆分为单价和数量。

第二范式（2NF）即确保表中的每列都和主键相关

在1NF的基础上，非码属性必须完全依赖于候选码（在1NF基础上消除非主属性对主码的部分函数依赖）

主键是用于唯一的标识表中的某一条记录，所以表中其他列和主键相关其实大白话意思就是，表的功能是干什么的就是专门存这个功能的信息，不要多存冗余的，要是有关联关系，可以用外键关键。

比如说一个商品娃娃，它的公司是娃娃公司，公司注册的地方是美国，注册时间时间是去年，那么去年和美国是公司的属性不是娃娃的属性。你想要通过娃娃知道公司的注册地和注册时间，可以在娃娃的表里外键关联到某个公司。切不能在娃娃的表里存公司的地址和注册时间。

第三范式（3NF）即除主键外，列和列不能间接相关

在2NF基础上，任何非主属性不依赖于其它非主属性（在2NF基础上消除传递依赖）

因为内存不够用，所以要减少冗余字段。例如，毛利=销售总额-销售成本。那么数据库设计的时候如果含有销售总额和销售成本，那么毛利也会被计算出来。因此设计数据库的时候销售总额，销售成本和毛利三者只能存在其二。

用通俗的话来讲，就是数据库第三范式不允许出现某一个属性能通过其他属性准确推断出来。

反三范式

三范式的提出是因为之前内存不够用。但是如今可以进步到内存已经不是问题。所以为了计算方便，第一范式和第三范式基本上不需要在考虑。例如一个大订单（订单内有很多种商品），如果没有每个商品的商品总金额，只有商品单价和数量，我们计算总价的时候需要数据库取出这些数据在放到内存中逐个求和，其实很不方便，如果数据库设计的时候有总和的一列，那么我们直接sum（商品总金额）where  orderId=#{orderId}可以直接取出方便了很多。

数据库设计注意事项

基础规范

必须使用InnoDB存储引擎

支持事务、行级锁、并发性能更好、CPU及内存缓存页优化使得资源利用率更高

新库默认使用utf8mb4字符集

     utf8mb4是utf8的超集，emoji表情以及部分不常见汉字在utf8下会表现为乱码，故需要升级至utf8mb4。

     默认使用这个字符集的原因是：“标准，万国码，无需转码，无乱码风险”，并不“节省空间”。

数据表、数据字段必须加入中文注释

    N年后谁tm知道这个r1,r2,r3字段是干嘛的，别人接收项目的时候也会了解。//代码不写注释是流氓，数据库也是

禁止使用存储过程、视图、触发器、Event

    高并发大数据的互联网业务，架构设计思路是“解放数据库CPU，将计算转移到服务层”，并发量大的情况下，这些功能很可能将数据库拖死，

    业务逻辑放到服务层具备更好的扩展性，能够轻易实现“增机器就加性能”。数据库擅长存储与索引，CPU计算还是上移吧

禁止存储大文件或者大照片 

     为何要让数据库做它不擅长的事情？大文件和照片存储在文件系统，数据库里存URI多好

命名规范

库名、表名、字段名：小写，下划线风格，不超过32个字符，必须见名知意，禁止拼音英文混用

字段设计规范

必须把字段定义为NOT NULL并且提供默认值

1.    null的列使索引/索引统计/值比较都更加复杂，对MySQL来说更难优化
2.    null 这种类型MySQL内部需要进行特殊处理，增加数据库处理记录的复杂性；同等条件下，表中有较多空字段的时候，数据库的处理性能会降低很多
3.    null值需要更多的存储空，无论是表还是索引中每行中的null的列都需要额外的空间来标识
4.    对null 的处理时候，只能采用is null或is not null，而不能采用=、in、<、<>、!=、not in这些操作符号。如：where name!=’shenjian’，如果存在name
5.    为null值的记录，查询结果就不会包含name为null值的记录

禁止使用TEXT、BLOB类型

  会浪费更多的磁盘和内存空间，非必要的大量的大字段查询会淘汰掉热数据，导致内存命中率急剧降低，影响数据库性能

禁止使用小数存储货币

   使用整数吧，小数容易导致钱对不上 小数*100

必须使用varchar(20)存储手机号

1.    涉及到区号或者国家代号，可能出现+-()
2.    手机号会去做数学运算么？
3.    varchar可以支持模糊查询，例如：like“138%”

禁止使用ENUM，可使用TINYINT代替