外键约束、级联操作与完整性、一致性问题
1613 2021-06-12 09:27
在阿里的JAVA规范中有：【强制】不得使用外键与级联，一切外键概念必须在应用层解决。
上学的时候按照范式要求，减少信息冗余，就要保证信息的完整性和一致性。
除此之外还要限定数据的唯一性。
范式理论
范式可以避免数据冗余，减少数据库的空间，减轻维护数据完整性的麻烦。
- 第一范式：强调列要具有原子性，不可拆分性(最小)
- 第二范式：记录的唯一性约束
- 第三范式：强调属性冗余性的约束，不能由其他列计算得来
- 很多时候也会违反
那么外键约束、级联操作就是数据库为我们提高效率、节省代码，所安排的功能。
但实际生产过程中为什么我们又强制不可使用？
首先，现实是残酷的、不是理想主义的、是总会有垃圾和bug的。当你产生了订单，发现商品下架了。那么你的订单记录已经是历史了，在数据库看来，作废的、过期的都应该消灭。但是在你看来，历史就应该有痕迹。
完整性要求主键唯一，引用可查，非空、默认值、默认长度。
一致性要求事务要么全做要么全撤（原子性）、某一个状态下都安生了发生故障也不怕，可以备案了（持久性）、事务彼此之间互不影响（隔离性）
个人理解：第一范式，原子性、解决一条记录中类似地址信息的字段，比如程序需要选定下拉菜单为 、省级、市级、区县、街道。那么一个字段来表示地址属性，就不满足第一范式的要求。因为有很多省、市、区县都重复了。数据冗余过大，另外，无法在没有记录的情况下，提前建立省、市、区县的数据字典表，这些是不用有记录就可以提前制作的。并且，你删除了记录，但是这些地理数据的关联数据-字典表，依然是存在的。当你修改了一个合并了的东城区崇文区、西城区宣武区的时候，你只需要修改字典表，而不需要更改数据表。
第二范式，唯一性、解决第一范式的属性被拆分后，重复码的问题。码不代表id，id是每个表需要生成的主键，而码代表了一条记录的唯一性。防重复。
第三范式，冗余性、解决了第二范式的传递依赖问题。
解决了数据冗余过大，插入异常，修改异常，删除异常的问题
实际设计中、主键都被视作id，而码则被抛弃了。防止重复都用插入前的应用程序检验来完成。
mysql多列索引
分类
热门文章
Tags
关于
提供Arduino芯片编程、Java网站设计、抢票系统、秒杀系统的支持以及创客服务
全部评论