外键约束、级联操作与完整性、一致性问题

1213 2021-06-12 09:27

在阿里的JAVA规范中有:【强制】不得使用外键与级联,一切外键概念必须在应用层解决。

上学的时候按照范式要求,减少信息冗余,就要保证信息的完整性和一致性。

除此之外还要限定数据的唯一性。

范式理论

​ 范式可以避免数据冗余,减少数据库的空间,减轻维护数据完整性的麻烦。

  • 第一范式:强调列要具有原子性,不可拆分性(最小)
  • 第二范式:记录的唯一性约束
  • 第三范式:强调属性冗余性的约束,不能由其他列计算得来
    • 很多时候也会违反

 那么外键约束、级联操作就是数据库为我们提高效率、节省代码,所安排的功能。

但实际生产过程中为什么我们又强制不可使用?

首先,现实是残酷的、不是理想主义的、是总会有垃圾和bug的。当你产生了订单,发现商品下架了。那么你的订单记录已经是历史了,在数据库看来,作废的、过期的都应该消灭。但是在你看来,历史就应该有痕迹。

完整性要求主键唯一,引用可查,非空、默认值、默认长度。

一致性要求事务要么全做要么全撤(原子性)、某一个状态下都安生了发生故障也不怕,可以备案了(持久性)、事务彼此之间互不影响(隔离性)

 

个人理解:第一范式,原子性、解决一条记录中类似地址信息的字段,比如程序需要选定下拉菜单为 、省级、市级、区县、街道。那么一个字段来表示地址属性,就不满足第一范式的要求。因为有很多省、市、区县都重复了。数据冗余过大,另外,无法在没有记录的情况下,提前建立省、市、区县的数据字典表,这些是不用有记录就可以提前制作的。并且,你删除了记录,但是这些地理数据的关联数据-字典表,依然是存在的。当你修改了一个合并了的东城区崇文区、西城区宣武区的时候,你只需要修改字典表,而不需要更改数据表。

第二范式,唯一性、解决第一范式的属性被拆分后,重复码的问题。码不代表id,id是每个表需要生成的主键,而码代表了一条记录的唯一性。防重复。

第三范式,冗余性、解决了第二范式的传递依赖问题。

 

解决了数据冗余过大,插入异常,修改异常,删除异常的问题

 

实际设计中、主键都被视作id,而码则被抛弃了。防止重复都用插入前的应用程序检验来完成。

mysql多列索引

全部评论

·