前言

咱们常常听到范式设计与反范式设计，那么什么时候该遵循范式设计？什么时候又该违反他的规定呢？带着这两个问题，让我当初带你钻研～

范式

范式就是前辈通过一直的验证给到的为了建设冗余较小、结构合理的数据库，是设计数据库必须遵循的肯定规定，在关系型数据库中这种规格叫做范式，本篇不仅阐明范式设计，也会给到一些例子，带着各位一起剖析给到的数据表设计属于第几范式。

1NF 第一范式

遵循的规定：每一列属性都是不可再分的属性值，确保每一列的原子性

啥玩意是不再可分？例如用户名、性别、年龄联系方式则就是不能再分了。
但例如城市，北京市通州区，咱们还是能够再分的，将一个字段分为省：北京市 区：通州区

首先，咱们看到用户信息表中，所在城市是能够在进行细分的。

下表咱们根据上述用户信息表，将城市分为省和市两个字段，这样设计后，该数据表则合乎了第一范式的要求。

咱们再以商品表做一个阐明

仍旧是按照上述规定，首先咱们找到已无奈再次宰割的属性

当初不可再宰割的属性有 编码、价格（以只有RMB为准）、库存，而商品名称及制作工厂想必大家也晓得，这是能够再分的属性吧，那么看下方合乎第一范式的数据表设计

咱们将商品名称与制作工厂进行以下的拆分，以达到不可再分的属性

其关系模式为：

商品名称（品牌,型号,色彩）
制作工厂（制作工厂所在城市,制作工厂名称）

看到这里，想必你曾经搞懂第一范式的设计规定了，那么咱们持续第二范式的学习。

2NF 第二范式

遵循的规定：首先必须合乎第一范式要求，其次一个表中只能保留一种数据,确保每一列都与主键相干，咱们以课程编码为主键，除课程名称以外的其余信息与主键无关，所以咱们只须要独立课程编码与课程名称，其余则新建一张表。

课程表

老师表

这样拆分后，咱们就合乎了第二范式的要求，并且也合乎第一范式的要求，没有可再分的属性。

咱们再以上述合乎第一范式的商品表为例

这里以编码和品牌为联结主键，与主键无关的属性新建设一张表。

生产商表

商品表

这样既合乎了第二范式要求。

咱们曾经对第二范式有了一个大略得理解，不要停，第三范式在等你！

3NF 第三范式

遵循的规定：要先合乎第二范式的要求，并且除主键列的其它列之间，不能有传递依赖关系。

这里先解释下，啥是传递依赖，以下列订单表为例 ，咱们通过订单编码能够查到商品名称，但通过商铺编码也能够查找到发货仓及联系方式。既订单编码->发货仓，商铺编码->发货仓，这则产生传递依赖，艰深点考究是如果除了主键（订单编码）外，不能再有有属性相干的非主键（商铺编码|发货仓），咱们只能通过主键查到所有信息，达到独占的状况，意味着下条SQL语句不能让他无效，则就达到了第三范式的要求。

SELECT 发货仓,店铺电话 FROM 订单表 WHERE 商铺编码 = S1

依据下述拆分达到第三范式要求

订单表

商铺表

刚刚讲到第三范式肯定满足第二范式，而第一范式肯定满足第一范式，那么咱们看下刚刚拆好的订单表

1. 无再可拆分的属性，合乎第一范式。
2. 无与主键无关属性，合乎第二范式。
3. 无传递依赖关系，合乎第三范式。

所以说，当你合乎第三范式时，你理论曾经合乎了第一第二范式，那么关系型数据库的三大范式咱们就讲到这里，数据中可能有些歧义，请了解原理，勿细纠结，谢谢。

反范式设计的目标

当然范式只是提出的标准，但一些非凡状况下，咱们要思考的点比拟多，例如

1. 并发读。
2. 缩小表关联次数。
3. 数据表的冗余设计。
4. 热数据与冷数据。
5. 数据的非实时性。

这里与三大范式做一个比照（个人见解）

• 缩小表关联次数 = 违反了第二范式
• 数据表的冗余设计 = 违反了第三范式

当然也不是一概而论，这里以订单表为导向，来解说一下为什么咱们会无可奈何违反范式规定。

这里做出一个发问

用户下单后，商品的根本信息如果进行表关联的形式，既订单表的商品编码关联商品表的编码，会呈现什么问题？

大略会呈现这样一个问题：

用户购买了一台HP打印机1999元后，商家对以后这个商品进行了批改，改为了一台华硕笔记本，那么通过表关联（设合乎范式规定），用户会不会疯掉？

那么如何解决这一问题？

这就应用了我上述提出的数据的冗余设计，将商品根本信息间接存入订单表中，这是依据常识而定的，就跟你去商场买了一个西瓜花了20元，次日这个西瓜无论跌价还是提价，商场不会要求你补足差价，你也无奈要求商场返还差价（当然这与某东买贵包赔无关，不要较劲）。

那么在互联网的时代，当你下单的那一时刻，你购买的商品信息则就曾经固定，无论商家是批改商品，还是删掉商品，或者商家开张了敞开店铺。你购买的商品永远会在你的订单内看到，当然如果商品生效，你在点击进入后，某宝可能会给到你一个快照，这个快照仍旧是在你下单时保留的数据。

你当初应该能够了解，为什么须要反范式，相似的例子还有很多，我在我的电商设计相干文章内有屡次提出相似的需要，至此我就不一一例举了

当然在失常状况下，你仍旧须要依据三大范式去设计你的业务，这是行业标准，只有标准对立，你才不会太“坑”你的接锅班人。

那么反范式设计的长处有哪些呢？

1. 进步查问速度。
2. 防止多表查问。
3. 升高数据库的压力。

反范式应该留神的问题

1. 过多冗余数据导致存储量过大。
2. 必要时需配合内存数据库履行。
3. 违反了范式规定，会呈现插入异样、查问异样等。

致谢

感激你看到这里，心愿本篇能够帮忙到你，谢谢。