数据库建表是否使用外键

数据库建表是否使用外键

更多干货

• 分布式实战（干货）

• spring cloud 实战（干货）

• mybatis 实战（干货）

• spring boot 实战（干货）

• React 入门实战（干货）

• 构建中小型互联网企业架构（干货）

• python 学习持续更新

• ElasticSearch 笔记

• kafka storm 实战 (干货)

• scala 学习持续更新

• RPC

• 深度学习

• GO 语言 持续更新

• Android 学习

• nginx 相关文章

一：使用外键

优点：

• 实现表与关联表之间的数据一致性；

• 可以迅速的建立一个可靠性非常高的数据库结构，而不用让应用程序层去做过多的检查；

• 可以提高系统鲁棒性、健壮性；

• 可以实现开发人员和数据库设计人员的分工；

缺点：

• 数据库需要维护外键的内部管理；

• 外键等于把数据的一致性事务实现，全部交给数据库服务器完成；

• 有了外键，当做一些涉及外键字段的增，删，更新操作之后，需要触发相关操作去检查，而不得不消耗资源；

• 外键还会因为需要请求对其他表内部加锁而容易出现死锁情况；

• 容易出现数据库I/O的瓶颈；

二：不使用外键

优点：

• 减少了数据库表与表之间各种关联的复杂性；

• 牺牲应用服务器资源，换取数据库服务器的性能；

• 将主动权把控在自己手里；

• 去掉外键相当于优化数据库性能；

缺点：

• 所有外键的约束，需要自己在逻辑层自己实现；

• 会出现数据错误覆写，错误数据进库的情况；

• 消耗了服务器的性能；

• 业务层里夹带持久层特性，耦合；

总结：

1、互联网行业：不推荐使用外键。

理由：

• 用户量大，并发度高，为此数据库服务器很容易成为性能瓶颈，尤其受IO能力限制，且不能轻易地水平扩展；

• 若是把数据一致性的控制放到事务中，即让应用服务器承担此部分的压力；

• 应用服务器一般都是可以做到轻松地水平的伸缩；

2、传统行业：可以使用。

理由：

• 软件应用的人数有限，换句话说是可控的；

• 数据库服务器的数据量也一般不会超大，且活跃数据有限；