对mysql建表三范式的理解

对mysql建表三范式的理解

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

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

为什么这么说,你看看三范式在说啥:

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

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

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

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

你可能感兴趣的:(mysql)