为什么要拆表,而不使用大宽表记录所有

最近有个小伙伴自学中了解到了大宽表,然后对我吐槽,学校老师教的都是粑粑,搞了一堆表,浪费时间和精力......

首先为他老师难受三秒钟,但是更大的问题是怎么才能让这个小伙伴理解为啥要拆表呢?费脑子啊!!!

一、何为大宽表

大宽表(Wide Table)是指在数据库中采用一张包含大量列的表。通常情况下,每一列都包含了不同的数据属性或字段。

相较于传统的规范化数据库设计,大宽表更加扁平化,将多个数据属性存储在同一张表中。这种设计方式可以方便地将相关数据聚合在一起,并且可以减少数据表之间的关联操作。

从上面可以看出,所谓的大宽表就是把所有数据用一条记录存在一个表里面,那么问题来了

graph LR A(大宽表可能引发的问题) B(冗余数据) C(数据一致性) D(索引和性能) A ---> B A ---> C A ---> D style B fill:#FFC0CB,stroke:#FFC0CB,stroke-width:2px style C fill:#FFA07A,stroke:#FFA07A,stroke-width:2px style D fill:#FFFFE0,stroke:#FFFFE0,stroke-width:2px
  • 冗余数据 :大宽表中的每一行都包含了所有的数据属性,可能会导致数据冗余。如果多个数据属性之间的关联性较小,这种冗余可能会浪费存储空间

  • 数据一致性:由于所有数据都存储在一张表中,当需要更新某个数据属性时,可能需要修改整张表的数据,这可能会引起数据一致性的问题。

  • 索引和性能:大宽表的索引设计可能更加复杂,因为需要考虑到多个数据属性的查询需求。此外,大宽表中的数据量可能较大,对于大规模的数据集,性能可能会受到影响。

二、为何拆表

实际在我们的业务开发中,开发人员设计数据库表的时候一般都要遵循数据库表设计的三范式。别问为啥,这是无数前辈在以往的开发工程中总结的经验,你拿来用就得了。当然这么解释也是很难说的服的,难受啊!!!

既然出了数据库表设计的三范式,那么它肯定有一些优点的,下面我将详细说说这些优点。

graph LR A(拆表的优点) B(性能优化) C(水平扩展) D(避免锁竞争) E(简化维护) F(避免全表扫描) G(数据组织) H(事务隔离) I(数据分区) A ---> B A ---> C A ---> D A ---> E A ---> F A ---> G A ---> H A ---> I style B fill:#FFC0CB,stroke:#FFC0CB,stroke-width:2px style C fill:#FFA07A,stroke:#FFA07A,stroke-width:2px style D fill:#FFFFE0,stroke:#FFFFE0,stroke-width:2px style E fill:#98FB98,stroke:#98FB98,stroke-width:2px style F fill:#B2FFFF,stroke:#B2FFFF,stroke-width:2px style G fill:#ADD8E6,stroke:#ADD8E6,stroke-width:2px style H fill:#E6E6FA,stroke:#E6E6FA,stroke-width:2px style I fill:#EEDD82,stroke:#EEDD82,stroke-width:2px
  • 性能优化:随着数据量的增长,单个表可能会变得非常大,导致查询和写入操作变慢。拆分表可以减少单个表的数据量,提高查询效率,因为数据库可以更快地在较小的数据集上执行操作。

  • 水平扩展:在分布式系统中,通过水平拆分(分表)可以将数据分散到多个数据库实例中,这样可以利用更多的硬件资源,提高系统的处理能力和扩展性。

  • 避免锁竞争:在高并发场景下,大表可能会因为锁竞争导致性能瓶颈。拆分表可以减少锁的竞争,因为每个表的数据量减少,锁的范围也相应缩小。

  • 简化维护:大表的维护(如备份、恢复、迁移)可能会非常耗时。拆分表后,可以更容易地管理这些操作,因为每个表的数据量较小。

  • 避免全表扫描:在大表中,即使只查询少量数据,也可能需要进行全表扫描,这会消耗大量资源。拆分表后,可以减少不必要的数据扫描,提高查询效率。

  • 数据组织:有时候,某些字段可能只在特定情况下被查询,将这些字段拆分到单独的表中,可以减少不必要的数据冗余,提高存储效率。

  • 事务隔离:在某些情况下,拆分表可以帮助实现更细粒度的事务控制,因为可以对单个表进行事务操作,而不是整个大表。

三、大宽表的应用场景

当然,存在即合理;大宽表既然一直都在,肯定是有他的用处的;按照我上面的说法,大宽表不适用一般的业务开发中,那他到底适合哪些场景呢?我找了找,他适用的场景也蛮多的。

graph LR A(大宽表适用场景) B(分析和报表生成) C(快速数据检索) D(跨系统集成) E(数据缓存和快速访问) F(简化数据模型) A ---> B A ---> C A ---> D A ---> E A ---> F style B fill:#FFC0CB,stroke:#FFC0CB,stroke-width:2px style C fill:#FFA07A,stroke:#FFA07A,stroke-width:2px style D fill:#FFFFE0,stroke:#FFFFE0,stroke-width:2px style E fill:#98FB98,stroke:#98FB98,stroke-width:2px style F fill:#B2FFFF,stroke:#B2FFFF,stroke-width:2px
  • 分析和报表生成:当需要进行大规模数据分析或生成复杂的报表时,大宽表可以方便地将相关数据聚合在一起,简化查询和分析操作。通过将多个数据属性存储在同一张表中,可以减少关联查询的复杂性,提高查询性能。

  • 快速数据检索:对于需要频繁进行数据检索和查询的场景,大宽表可以减少关联操作的数量,简化查询过程,提高检索速度。这对于那些需要快速获取数据的应用程序和系统非常有用。

  • 跨系统集成:在进行不同系统之间的数据集成时,大宽表可以提供一种简单而灵活的方式来存储和共享数据。通过将来自不同系统的数据属性存储在同一张表中,可以方便地进行数据转换和集成操作。

  • 数据缓存和快速访问:将常用的数据属性存储在大宽表中,可以作为数据缓存,提供快速访问和响应。这对于那些需要频繁访问和查询特定数据属性的应用程序非常有帮助。

  • 简化数据模型:在某些情况下,大宽表可以简化数据模型的设计和管理。特别是对于那些数据属性之间关联性较弱的场景,使用大宽表可以减少表之间的关联操作和复杂性。

四、总结

之所以写这个,不完全是为了说服对方;更是给自己一个交代,也许我给他看了之后还会被他想着怎么说服呢?咱不纠结,放过自己,写完就过。

希望本文对您有所帮助。如果有任何错误或建议,请随时指正和提出。

同时,如果您觉得这篇文章有价值,请考虑点赞和收藏。这将激励我进一步改进和创作更多有用的内容。

感谢您的支持和理解!

相关推荐
无风听海1 小时前
ASP.NET Core .NET 10 错误响应体系全景:从 BadRequest 到编译器基础设施
后端·asp.net·.net
文心快码BaiduComate1 小时前
从个人效能到组织资产:文心快码企业版Agent Hub上线,提升团队AI编程效能
前端·后端·程序员
雪隐2 小时前
个人电脑玩AI00-前言
人工智能·后端
数据库小学妹2 小时前
InnoDB内存架构解密:Buffer Pool与性能优化实战
数据库·经验分享·sql·性能优化·架构
Lyyaoo.2 小时前
【MySQL】SQL优化
android·sql·mysql
我是一颗柠檬2 小时前
【Java后端技术亮点】动态路由权限(按钮级权限),细粒度控制到按钮级别
java·开发语言·后端·状态模式
前端Hardy2 小时前
CSS 动画真的比 JS 快?Josh Comeau 做了组实验,结果跟直觉不一样
前端·javascript·后端
Front思2 小时前
调取支付宝支付正式环境不可以唤起来,但是沙箱可以
后端
foggyprojects2 小时前
AI 生成 SQL 模板以后,为什么还需要固定 helper 规则
后端
明天一点2 小时前
Cloudflare 通知转发钉钉机器人
前端·后端