数据库到底用不用外键

最近工作中用到powerdesigner ,前期需要通过powerdesigner生成表结构,后来由于负责人员不在,很多表结构的添加没有同步到powerdesigner,一个个核对表结构着实麻烦,于是想到到反向生成模型,但数据库没有外键关系导致生成的模型也没有外键。对项目中不用外键感到好奇于是问了相关人员原因,并简单了解了外键的特点和使用场景。为了进一步了解,在网上找了相关文章以下为转载的原文链接: 
http://www.cnblogs.com/pengxl/archive/2010/06/11/1756346.html

今天听了一个企业技术总监的宣讲,结果听说在他开发系统的过程中,都没有用到外键,这让我很惊讶,赶紧上网搜索了一些资料看了看,终于明白了不用外键的原因。

这是一篇关于是否使用外键的讨论,讲的很有道理: 
对于主/外键/索引来说,在一些开发团队中被认为是处理数据库关系的利器,也被某些开发团队认为是处理某些具体业务的魔鬼,您的观点呢?在实际应用中您会采取哪种方式? 
大家共同观点:主键和索引是不可少的,不仅可以优化数据检索速度,开发人员还省不其它的工作, 
矛盾焦点:数据库设计是否需要外键。这里有两个问题:一个是如何保证数据库数据的完整性和一致性;二是第一条对性能的影响。 
正方观点: 
1,由数据库自身保证数据一致性,完整性,更可靠,因为程序很难100%保证数据的完整性,而用外键即使在数据库服务器当机或者出现其他问题的时候,也能够最大限度的保证数据的一致性和完整性。eg:数据库和应用是一对多的关系,A应用会维护他那部分数据的完整性,系统一变大时,增加了B应用,A和B两个应用也许是不同的开发团队来做的。他们如何协调保证数据的完整性,而且一年以后如果又增加了C应用呢? 
2,有主外键的数据库设计可以增加ER图的可读性,这点在数据库设计时非常重要。 
3,外键在一定程度上说明的业务逻辑,会使设计周到具体全面。

反方观点: 
1,可以用触发器或应用程序保证数据的完整性 
2,过分强调或者说使用主键/外键会平添开发难度,导致表过多等问题 
3,不用外键时数据管理简单,操作方便,性能高(导入导出等操作,在insert, update, delete 数据的时候更快)eg:在海量的数据库中想都不要去想外键,试想,一个程序每天要insert数百万条记录,当存在外键约束的时候,每次要去扫描此记录是否合格,一般还不止一个字段有外键,这样扫描的数量是成级数的增长!我的一个程序入库在3个小时做完,如果加上外键,需要28个小时! 
结论:1,在大型系统中(性能要求不高,安全要求高),使用外键;在大型系统中(性能要求高,安全自己控制),不用外键;小系统随便,最好用外键。2,用外键要适当,不能过分追求3,不用外键而用程序控制数据一致性和完整性时,应该写一层来保证,然后个个应用通过这个层来访问数据库。

时间: 2024-10-08 12:18:10

数据库到底用不用外键的相关文章

sql数据库删除表的外键约束(INSERT 语句与 FOREIGN KEY 约束"XXX"冲突。该冲突发生于数据库"XXX",表"XXX", column 'XXX)

使用如下SQL语句查询出表中外键约束名称: 1 select name 2 from sys.foreign_key_columns f join sys.objects o on f.constraint_object_id=o.object_id 3 where f.parent_object_id=object_id('表名') 执行如下SQL语句删除即可. 1 alter table 表名 drop constraint 外键约束名 sql数据库删除表的外键约束(INSERT 语句与 F

数据库开发——参照完整性——在外键中使用Delete on cascade选项

原文:数据库开发--参照完整性--在外键中使用Delete on cascade选项 原文: http://www.mssqltips.com/sqlservertip/2743/using-delete-cascade-option-for-foreign-keys/?utm_source=dailynewsletter&utm_medium=email&utm_content=headline&utm_campaign=2012731 参照完整性在设计数据库时需要重视,在我作为

数据库建表需要外键约束吗?

建立外键的好处: 1) 由数据库保证数据完整性,比程序保证完整性更可靠, 多应用时(如有应用A,B,C他们之间的实体存在关联关系),由程序来保证数据完整性变得困难 2) 外键约束使得数据库的ER图可读性变强,有助于业务逻辑设计 不建立外键的好处: 1) 可以用触发器或应用程序保证数据的完整性 2) 开发变得简单,维护数据时不用考虑外键约束 3) 性能高,大数据量插入操作时不用考虑维护外键 讨论结果:不建立外键约束,关联关系由程序控制,另外还需要删除现有的外键关系

是否有必要使用外键?为什么不用外键?

正方(需要) 1.数据一致性 由数据库自身保证数据一致性,完整性,更可靠,因为程序很难100%保证数据 的完整性,而用外键即使在数据库服务器当机或者出现其他问题的时候,也能够最大限度的保证数据的一致性和完整性. eg:数据库和应用是一对多的关系,A应用会维护他那部分数据的完整性,系统一变大时,增加了B应用,A和B两个应用也许是不同的开发团队来做的.他们如何协调保证数据的完整性,而且一年以后如果又增加了C应用呢? 2.ER图可靠性 有主外键的数据库设计可以增加ER图的可读性,这点在数据库设计时非常

MySQL数据库之-foreign key 外键(一对多、多对多、一对一)、修改表、复制表

今日重点:外键 一对多 多对多      一对一 ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 一.引言: 我们在同一数据库创建的表时候,很多时候会出现相同数据的冗余问题,也就是说几个id

数据库外键使用

数据库到底用不用外键.触发器.索引.视图.存储过程 收藏 今天听了一个企业技术总监的宣讲,结果听说在他开发系统的过程中,都没有用到外键,这让我很惊讶,赶紧上网搜索了一些资料看了看,终于明白了不用外键的原因. 这是一篇关于是否使用外键的讨论,讲的很有道理: 对于主/外键/索引来说,在一些开发团队中被认为是处理数据库关系的利器,也被某些开发团队认为是处理某些具体业务的魔鬼,您的观点呢?在实际应用中您会采取哪种方式? 大家共同观点:主键和索引是不可少的,不仅可以优化数据检索速度,开发人员还省不其它的工

[转载]数据库外键的使用

[转载]数据库外键的使用 外键的作用: 保持数据一致性,完整性,主要目的是控制存储在外键表中的数据. 使两张表形成关联,外键只能引用外表中的列的值! 例如: a b 两个表 a表中存有客户号,客户名称 b表中存有每个客户的订单 有了外键后 你只能在确信b 表中没有客户x的订单后,才可以在a表中删除客户x 建立外键的前提: 本表的列必须与外键类型相同(外键必须是外表主键). 指定主键关键字: foreign key(列名) 引用外键关键字: references <外键表名>(外键列名) 事件触

数据库外键的使用

外键的作用: 保持数据一致性,完整性,主要目的是控制存储在外键表中的数据. 使两张表形成关联,外键只能引用外表中的列的值! 例如: a b 两个表 a表中存有客户号,客户名称 b表中存有每个客户的订单 有了外键后 你只能在确信b 表中没有客户x的订单后,才可以在a表中删除客户x 建立外键的前提: 本表的列必须与外键类型相同(外键必须是外表主键). 指定主键关键字: foreign key(列名) 引用外键关键字: references <外键表名>(外键列名) 事件触发限制: on delet

数据库主从表、关系;主、外键关系和作用

从数据库是主数据库的备份,当主数据库变化时从数据库要更新,这些数据库软件可以设计更新周期.这是提高信息安全的手段.主从数据库服务器不在一个地理位置上,当发生意外时数据库可以保存.主外键的关系结构:1,一对一,不用引用主外键,把它们放一个表中即可例如:一个学生只能有一个卡号,那么学生跟卡号放在一个表中即可2,一对多,引用主外键,'一'相当于主键,'多'即是引用主键的外键.例如:一个班级可以有多个学生,并且一个学生只能属于一个班级,这就是一对多的关系:3,多对多关系,需要创建一个表,表中需要两个字段