我们都知道每张数据表都有一个能够确定每行数据唯一性的字段,也就是主键。而在关系数据库中,常常有两表存在一定关系的情况。即一张表的主键跟另一张的外键存在对应关系,我们知道这种关系是存在的,那么我们在创建数据库表的时候是否一定要把外键关系约束加上呢?因为一旦创建了这个关系,在开发中就可能遇到莫名其妙的问题,所以我一般都是不设置外键关系,只设置主键约束。而两表的主外键关系在实际开发中通过程序来控制,达到数据的完整性,一致性。曾经在面试的时候遇到这样的问题,面试官反驳我的做法,但是我没有明白不设置主外键的关系与设置主外键关系的利害关系以及是否会设计到数据库的性能问题。谁能来讲解一下呢?
我最近也有碰到这个问题,我使用的是一个基于postgresql的分布式数据库,postgresql支持外键约束,分布式数据库不支持外键,让我很迷惑,我想通过powerdesigner来逆向导出数据库一些表的ER关系,发现没有约束的时候这样做很糟糕,只能导出基本的表结构,完全要手动操作。
感觉在一些大数据应用的系统一般不考虑外键约束可以提高性能,小型系统了、业务逻辑很强但是数据量不是很大的数据库一般会使用外键约束
想跟大家讨论,数据库建表需要外键约束吗?
Instrumentation and the cost of Foreign Keys
外键的存在是有意义的,例如一个人的基本信息和工资分别存放一张表。
如果有一天,你发现一个找不到基本信息的人,却有工资信息,问题就出现了。
外键约束毕竟是一个约束,只是保证数据完整性的一个手段。
数据库系统本身约束手段是更可靠的。
对于开发来说,可能觉得建立外键关系没必要,但是到了以后维护阶段,或升级阶段,如果没有这个关系,可能不利维护工作的提升。表关系的建立,也阐述着具体的业务逻辑关系,增加了可读性。
在逻辑性,关联性比较强的时候不妨添加。
其他时候简单的外键约束也是可以的,不需要一有关系就添加,但是要有其他机制保证数据完整性,毕竟外键对于开发有时候还是有限制。
总的来说前期开发可以不管,后期维护尽量转移到数据库本身的约束来建立关系。
我接触的信息系统,在建立数据表的时候,的确不建立外键约束。实际操作过程中,通过应用程序或触发器建立约束关系。这样在维护数据过程中比较方便
你的想法大体上是没有问题的,并且我在实际项目开发过程中也是这样做的,但你回答的没有做到滴水不漏,假如在你的回答后面再加上一句话就完美了。
所以我一般都是不设置外键关系,只设置主键约束,而两表的主外键关系在实际开发中通过程序来控制,达到数据的完整性,一致性。
当然了,具体的操作还需根据实际项目的架构来安排,对我本人来说这两种做法都无技术层面的问题。
目前实习接触的项目(题库),数据库里完全没有外键的约束,我想这样是为了在删除过程中不会报错吧。
-------------------------------------------------------------------------------------------
此外也方便以后对数据库进行分库和分表。
冗余设计可以提高查询的性能。