189 8069 5689

Mysql范式与反范式的详细说明

本篇内容主要讲解“MySQL范式与反范式的详细说明”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“Mysql范式与反范式的详细说明”吧!

10多年的来凤网站建设经验,针对设计、前端、开发、售后、文案、推广等六对一服务,响应快,48小时及时工作处理。网络营销推广的优势是能够根据用户设备显示端的尺寸不同,自动调整来凤建站的显示方式,使网站能够适用不同显示终端,在浏览器中调整网站的宽度,无论在任何一种浏览器上浏览网站,都能展现优雅布局与设计,从而大程度地提升浏览体验。创新互联建站从事“来凤网站设计”,“来凤网站推广”以来,每个客户项目都认真落实执行。

第一范式(1NF)

第一范式,强调属性的原子性约束,要求属性具有原子性,不可再分解。

举个例子:活动表(活动编码,活动名称,活动地址),假设这个场景中,活动地址可以细分为国家、省份、城市、市区、位置,那么就没有达到第一范式。

第二范式(2NF)

第二范式,强调记录的唯一性约束,表必须有一个主键,并且没有包含在主键中的列必须完全依赖于主键,而不能只依赖于主键的一部分。

举个例子:版本表(版本编码,版本名称,产品编码,产品名称),其中主键是(版本编码,产品编码),这个场景中,数据库设计并不符合第二范式,因为产品名称只依赖于产品编码。存在部分依赖。所以,为了使其满足第二范式,可以改造成两个表:版本表(版本编码,产品编码)和产品表(产品编码,产品名称)。

第三范式(3NF)

第三范式,强调属性冗余性的约束,即非主键列必须直接依赖于主键。

举个例子,订单表(订单编码,顾客编码,顾客名称),其中主键是(订单编码),这个场景中,顾客编码、顾客名称都完全依赖于主键,因此符合第二范式,但是顾客名称依赖于顾客编码,从而间接依赖于主键,所以不能满足第三范式。为了使其满足第三范式,可以拆分两个表:订单表(订单编码,顾客编码)和顾客表(顾客编码,顾客名称),拆分后的数据库设计,就可以完全满足第三范式的要求了。

值得注意的是,第二范式的侧重点是非主键列是否完全依赖于主键,还是依赖于主键的一部分。第三范式的侧重点是非主键列是直接依赖于主键,还是直接依赖于非主键列。

反范式

范式可以避免数据冗余,减少数据库的空间,减轻维护数据完整性的麻烦。 然而,通过数据库范式化设计,将导致数据库业务涉及的表变多,并且可能需要将涉及的业务表进行多表连接查询,这样将导致性能变差,且不利于分库分表。因此,出于性能优先的考量,可能在数据库的结构中需要使用反范式的设计,即空间换取时间,采取数据冗余的方式避免表之间的关联查询。至于数据一致性问题,因为难以满足数据强一致性,一般情况下,使存储数据尽可能达到用户一致,保证系统经过一段较短的时间的自我恢复和修正,数据最终达到一致。

需要谨慎使用反模式设计数据库。一般情况下,尽可能使用范式化的数据库设计,因为范式化的数据库设计能让产品更加灵活,并且能在数据库层保持数据完整性。

有的时候,提升性能最好的方法是在同一表中保存冗余数据,如果能容许少量的脏数据,创建一张完全独立的汇总表或缓存表是非常好的方法。举个例子,设计一张“下载次数表”来缓存下载次数信息,可使在海量数据的情况下,提高查询总数信息的速度。

另外一个比较典型的场景,出于扩展性考虑,可能会使用 BLOB 和 TEXT 类型的列存储 JSON 结构的数据,这样的好处在于可以在任何时候,将新的属性添加到这个字段中,而不需要更改表结构。但是,这个设计的缺点也比较明显,就是需要获取整个字段内容进行解码来获取指定的属性,并且无法进行索引、排序、聚合等操作。因此,如果需要考虑更加复杂的使用场景,更加建议使用 MongoDB 这样的文档型数据库。

真实场景很难做到范式化,一般会选择性能,保证最终一致性。

到此,相信大家对“Mysql范式与反范式的详细说明”有了更深的了解,不妨来实际操作一番吧!这里是创新互联网站,更多相关内容可以进入相关频道进行查询,关注我们,继续学习!


本文名称:Mysql范式与反范式的详细说明
文章链接:http://cdxtjz.cn/article/ghdcdj.html

其他资讯