🍊 Java学习：Java从入门到精通总结
🍊 Spring系列推荐：Spring源码解析
📆 最近更新：2022年3月16日
🍊 个人简介：通信工程本硕💪、Java程序员🌕。我的故事充满机遇、挑战与翻盘，欢迎关注作者来共饮一杯鸡汤
🍊 点赞 👍 收藏 ⭐留言 📝 都是我最大的动力！
各位同学大家好，又到了每年一度的金三银四的校招环节，相信很多同学们都已经开始紧锣密鼓的复习了吧，数据库也是一个很重要的知识点，很多人在初学数据库时一定听说过数据库设计的三大范式，不少人也会将其背诵得滚瓜烂熟
不过今天我想分享一个可能让某些同学觉得很毁三观的观点，那就是数据库设计的三大范式很可能已经不适合当前互联网的应用了，不要激动，且听我慢慢分析！
上面的三大范式总结起来其实就是两条：
- 1NF：字段必须具有原子性、不可分解
- 2NF & 3NF：数据库表中的字段应该主键相关、不做冗余
之所以说经典的数据库设计三大范式在当今互联网应用下基本上算是没用了，主要原因如下：
- 在现代互联网高流量的背景下，数据会被大量冗余到各张表里，如果使用三范式的话会把冗余全部剔除，在表与表之间做关联表。而我们则会经常用很多的大宽表来做冗余以方便查询，因为在真正超高并发应用下，join操作非常耗费数据库资源。
举一个例子，对于订单表来说，每一行数据会记录下每一个订单的具体信息，我们可以很容易通过订单id查询到订单数据；如果现在需求变成了要查询某个用户下的所有订单的话，如果使用join查询在流量大的背景下根本不可行。
一个常见的解决方案就是把订单数据按照用户id为维度再存储一遍，这样就可以通过用户id快速索引到相应的数据，是不是很方便？
- 互联网应用里有大量的快照信息需要保存（实际上就是商品、订单的版本控制）
为什么要保存订单快照呢？
这个问题也不难回答，目的就是为了防止之前用户购买的商品被下架、修改等等操作导致先前买的商品信息找不到了
- 除了上面说的订单数据可能分不同的维度冗余存储多份以外，还会采取异构存储的策略
所谓异构存储就是，数据除了要保存在MySQL里之外，还要在诸如Solr、opensearch、elasticsearch等搜索引擎里存一份，以满足用户搜索的请求
此外还要保存数据的历史记录（版本控制），如果要按传统的设计思路，订单快照通常是订单的历史版本，中间再做一个关联表，关联到商品的历史版本记录中，但实际上往往是对订单的快照信息做一个聚合，将营销计算结果、商品库的历史快照、用户信息等全部聚合在一起，将这一段数据冗余到订单库里面，完全打破了数据库的三大范式！
因此在互联网场景中，我们需要倡导的就是业务第一的原则，怎么快就怎么来。
做这么多冗余，数据的一致性又该如何保证？
其实很简单，数据一致性，分布式事务，数据同步都有非常成熟的解决方案，并且在大厂里已经经过广泛的生产级应用考验。
版权归原作者 小王曾是少年 所有， 如有侵权，请联系我们删除。