视频1 视频21 视频41 视频61 视频文章1 视频文章21 视频文章41 视频文章61 推荐1 推荐3 推荐5 推荐7 推荐9 推荐11 推荐13 推荐15 推荐17 推荐19 推荐21 推荐23 推荐25 推荐27 推荐29 推荐31 推荐33 推荐35 推荐37 推荐39 推荐41 推荐43 推荐45 推荐47 推荐49 关键词1 关键词101 关键词201 关键词301 关键词401 关键词501 关键词601 关键词701 关键词801 关键词901 关键词1001 关键词1101 关键词1201 关键词1301 关键词1401 关键词1501 关键词1601 关键词1701 关键词1801 关键词1901 视频扩展1 视频扩展6 视频扩展11 视频扩展16 文章1 文章201 文章401 文章601 文章801 文章1001 资讯1 资讯501 资讯1001 资讯1501 标签1 标签501 标签1001 关键词1 关键词501 关键词1001 关键词1501 专题2001
数据库设计之外键的思考
2020-11-09 14:45:37 责编:小采
文档


关于是否使用外键在业界也没有统一的标准,大家争论的焦点是数据一致性和性能上。 支持使用外键方 ,强调如果不使用外键,数据一致性无法保证,性能消耗可以忽略。 反对使用外键方 ,数据一致性可以通过程序保证,性能有大问题,数据维护很麻烦,如果是大系

关于是否使用外键在业界也没有统一的标准,大家争论的焦点是数据一致性和性能上。

支持使用外键方,强调如果不使用外键,数据一致性无法保证,性能消耗可以忽略。

反对使用外键方,数据一致性可以通过程序保证,性能有大问题,数据维护很麻烦,如果是大系统,整个外键的关系就像编制的一张大网。再者开发人员很难真正用好外键。

其实两种观点我都支持,现状是我基本没用过外键。没使用外键会出现什么问题呢?

1.数据一致性无法保证。出现这种情况最多的情况是,如A表示基础表,它被很多模块引用,B表是业务表,A表中删除了数据,B表的数据关联A的信息没有删除,导致写SQL时会出现大量的外连接。

2.从表上没有建索引。如果从表上有外键,这种情况悲剧就要发生了。请看参考我之前写的 外键不加索引引起的性能问题

3.使用外键在后台修改数据非常麻烦,当然这个不是外键的问题,只是系统自身的问题。

你看任何一本涉及到数据库设计的书籍,都会告诉你一定要使用外键,但理想和实现总是有点差距,如何选择,我的建议:

1.如果你对数据一致性要求非常高,关乎人命,钱,一定要加外键,像财务系统等。反之,可以牺牲一下,换取方便。

2.如果不加外键,基础的表(就是会被引用的表)要做逻辑删除(加一个删除的标识位),可以避免大量的外连接。

3.不管是否加外键,一定要索引。

下载本文
显示全文
专题