我想要做一款小程序，但是不知道数据库该怎么设计，怎么办？
相信有许多开发者都会有这样的疑问。虽然目前大家使用知晓云开发小程序，已经不再需要考虑后端代码的实现，只需要关心前端业务逻辑的展示即可。但对于想要实现复杂业务的小程序开发者来说，后台数据库到底是建一张表还是多张表、每张表分别存储什么信息、表与表之间如何关联等等问题仍然是一个令人头疼的问题。
如果在小程序实现之初只是草草定了一个基本架构，随意的建了几张表。万一哪天你的小程序火了，涌进大批用户，却因为数据库设计的原因导致数据访问缓慢，增删改查各种异常。虽然引得来用户，却留不住，该是何等可惜的一件事。
那既然数据库如此重要，到底该如何设计呢？其实只要了解并遵循数据库设计的三范式，就已经足够应付绝大部分场景了。
数据库设计的三范式
今天我们就以胜者唯电商小程序的数据库设计为例，为大家介绍一下什么是三范式。
1. 将数据按照逻辑思维分成不同的块
这个规则其实就是「三范式」中的第一范式（1 NF），即属性具有原子性，不可再分解。（字段是最小的的单元不可再分）
例如下面的图表，如果你想统计用户的城市分布情况，在没有对原始表进行拆分时，会非常痛苦。而随着脏数据的增加，拆分的工作会变得更加困难。
2. 将重复、不统一的数据视作你最大的敌人
仅仅只是完成初步的数据拆分，仍然会面临许多问题。
比如下面这张订单表，当同一个用户购买了多次同样的产品时，在收货地址这部分会出现大量的冗余数据。而当我们清空订单数据时，用户的地址信息也跟着被清空了。
根据第二范式（2NF）的要求：唯一性约束，每条记录有唯一标示。即一行数据只做一件事。只要数据列中出现数据重复，就要把表拆分开来。
我们把邮寄信息从原表中拆出，通过主键 address_book_id 相关联。这样当订单被删除时，也不会影响到用户的地址信息。
3. 当心数据依赖
第三范式（3NF）是对冗余性的约束，即非主键字段间不能相互依赖。
这要求每属性都跟主键有直接关系而不是间接关系。像：a➝b➝c 属性之间含有这样的关系，是不符合第三范式的。比如下面这张图表：
当然，实际设计过程中不会向上述实例一样简单，且三大范式只是一般设计数据库的基本理念，可以建立冗余较小、结构合理的数据库。
如果有特殊情况，当然要特殊对待，毕竟数据库设计最重要的是看需求跟性能，需求> 性能> 表结构。所以不能一味的去追求范式建立数据库。
读完之后还是不知从何下手？没关系\（￣）￣）/ 请往下看
