对mysql建表三范式的理解

对mysql建表三范式的理解

mysql三范式：
第一范式(确保每列保持原子性)【属性不可分】
第二范式(确保表中的每列都和主键相关)【符合第一范式，同时非主属性完全依赖于主键】
第三范式(确保每列都和主键列直接相关,而不是间接相关)【符合2NF，并且消除传递依赖】

再次看到这三范式，我第一感觉是：抠！是对磁盘空间的极致节约，相同的数据能不冗余，就不冗余。
这是什么时代的思想——pc端web、昂贵的机械硬盘存储时代。

为什么这么说，你看看三范式在说啥：

• 列原子性，就是把每个字段划分到不能划分为止，比如：
  • 一个字段保存了用户的 性别、年龄——这样保存势必导致数据类型不清晰，最后沦为字符串（大小不清楚了）
  • 把性别、年龄分开，性别用 ENUM，年龄用 TINYINT—— 严格限制了字段的大小，并且 枚举类型 类型占那么点空间（更节约）
  • 那么列原子性是不是就是在尽量严格控制数据类型，防止存储空间浪费
• 范式二主要是针对联合主键，除非所有字段都严格和联合主键先关才创建联合主键的表，否则，拆分建表。
• 数据关联，各个实体遵循第一第二范式，拆分了字段、拆分了表，尽可能使数据粒度变小，变小之后再创建数据关联——1/1、 1/n 、n/m ，关联的数据都用主键作为整条数据的代表去关联，就像是用内存的指针地址代表内存中的数据！

mysql就是尽可能地减少数据冗余，能只保存一次的数据就不要保存两次，然后把外键当做指针地址一样保存下来，需要数据的时候关联去查找；设计思路妥妥地清晰，但问题是联合查询的效率呢？慢归慢，在并没有那么苛求效率而存储成本又高的时代，这样极致节约空间的设计不是很划算吗？

随着磁盘价格下降、程序性能要求激增的将来、甚至当下，越来越多的开发者追求的是性能，适量的冗余是可以接受的。许多nosql数据库的就是为了迎合时代设计的，并不是它们比mysql的设计思路好，也不是他们的设计者比mysql牛逼，但是他们抓住了时代的需求，要快，多存点没关系。所以现在有了mongo、时序数据库、甚至为了快速查找而非节约空间的列式存储。

不得不说，mysql的设计者们在精益求精的精神在牛逼都路上一骑绝尘，现在的迎合时代的数据库还有些路要走，可不要在速度中迷失了技术人的苛求和初衷。