34,593
社区成员
发帖
与我相关
我的任务
分享讨论外键在数据库设计中的地位。
我先起个引子。
毫无疑问很多人都会对外键维护的复杂进行妥协，对它的性能产生怀疑，但在下一直固执的认为，外键就是系统完成性的一部分，不但要使用，而且要在符合语义环境的前提下尽量多的使用。
毫无疑问很多人都会对外键维护的复杂进行妥协，对它的性能产生怀疑，但在下一直固执的认为，外键就是系统完成性的一部分，不但要使用，而且要在符合语义环境的前提下尽量多的使用。
...全文
请发表友善的回复…
发表回复
mengmou 2007-09-12
- 打赏
- 举报
邹老大快出来讲讲啊。
hb_gx 2007-09-12
- 打赏
- 举报
外键还是少用或者不用，在程序中判断就很好了
其实就我个人认为最重要的是在开发和测试阶段太多的外键，影响工作，降低效率
其实就我个人认为最重要的是在开发和测试阶段太多的外键，影响工作，降低效率
PhilexPei 2007-09-12
- 打赏
- 举报
to fellowcheng(鹰击长空)
是否可以用异常来代替那些复杂的逻辑检查呢？
是否可以用异常来代替那些复杂的逻辑检查呢？
PhilexPei 2007-09-12
- 打赏
- 举报
to： wangtiecheng(不知不为过，不学就是错！)
我试着量化一下吧，这里说到外键的性能，肯定就要涉及到索引的性能，是否可以这么说除了那些不断大量增加数据的表，包含大量历史数据表，要慎重考虑性能，而其它的那些表，则必须要考虑外键。
我试着量化一下吧，这里说到外键的性能，肯定就要涉及到索引的性能，是否可以这么说除了那些不断大量增加数据的表，包含大量历史数据表，要慎重考虑性能，而其它的那些表，则必须要考虑外键。
dobear_0922 2007-09-12
- 打赏
- 举报
需要关联约束的地方，全部由前台代码保证
-------------------------------------
这是很危险的，一个小小的bug或者一次误操作就可能使数据库中的数据违反业务逻辑。
---------------------
确实如此，那个系统用长了就会产生一些垃圾数据，这些垃圾数据在前台永远都用不到，不过也不影响系统正常运转，，，
-------------------------------------
这是很危险的，一个小小的bug或者一次误操作就可能使数据库中的数据违反业务逻辑。
---------------------
确实如此，那个系统用长了就会产生一些垃圾数据，这些垃圾数据在前台永远都用不到，不过也不影响系统正常运转，，，
sp4 2007-09-12
- 打赏
- 举报
外键 我是经常用的，尤其是关系比较多的主表 与子表关系。
因为代码来维护这个感觉成本太高。
当然对于一些逻辑关系比较平淡的实体，可以忽略。
总之这东西不建议完全抛弃，毕竟是个好东西。
性能损失是有的，适当应用，我觉得挺好的
因为代码来维护这个感觉成本太高。
当然对于一些逻辑关系比较平淡的实体，可以忽略。
总之这东西不建议完全抛弃，毕竟是个好东西。
性能损失是有的，适当应用，我觉得挺好的
PhilexPei 2007-09-12
- 打赏
- 举报
to：wgzaaa
“实际中的逻辑不可能象程序员要求的那样严格” 说的很实在。
“实际中的逻辑不可能象程序员要求的那样严格” 说的很实在。
PhilexPei 2007-09-12
- 打赏
- 举报
相信到这个帖子来讨论的人，都是经历过不少系统设计工作的，今天拿这个很老套的问题出来讨论，就是想把很多问题量化、实例化，答疑解惑，分享经验，以怡后学。
mengmou 2007-09-12
- 打赏
- 举报
需要关联约束的地方，全部由前台代码保证
-------------------------------------
这是很危险的，一个小小的bug或者一次误操作就可能使数据库中的数据违反业务逻辑。
-------------------------------------
这是很危险的，一个小小的bug或者一次误操作就可能使数据库中的数据违反业务逻辑。
fellowcheng 2007-09-12
- 打赏
- 举报
前台逻辑保证完整性采用的还是多的
OracleRoob 2007-09-12
- 打赏
- 举报
如果程序能做到很严谨，外键少，固然能提高数据库性能，但往往程序的严谨性很难保证，需要合理的平衡外键与性能的关系。
wgzaaa 2007-09-12
- 打赏
- 举报
外键多复杂谈不上，不过实际中的逻辑不可能象程序员要求的那样严格，所以还是少用
PhilexPei 2007-09-12
- 打赏
- 举报
to : libin_ftsafe(子陌红尘：TS for Banking Card)
当然凡事得有度，我们可就这个度做一个衡量。
先说你提到的这一点吧，程序逻辑对数据完整性的检查和使用外键作为对数据完成性检查的优缺点。
当然凡事得有度，我们可就这个度做一个衡量。
先说你提到的这一点吧，程序逻辑对数据完整性的检查和使用外键作为对数据完成性检查的优缺点。
lost_queen 2007-09-12
- 打赏
- 举报
我个小屁孩也来说一句：
我觉得外键在很多情况下是必要的，它能让使用者少操很多心。
对于使用者来说，设计合理的外键能大大减低SQL语句的复杂性。
当然，如果外键的存在大幅降低了效率，或者让维护者无所适从的时候，也可以考虑使用其他方法保证完整性。
我觉得外键在很多情况下是必要的，它能让使用者少操很多心。
对于使用者来说，设计合理的外键能大大减低SQL语句的复杂性。
当然，如果外键的存在大幅降低了效率，或者让维护者无所适从的时候，也可以考虑使用其他方法保证完整性。
dobear_0922 2007-09-12
- 打赏
- 举报
偶以前做的一个项目就完全没有外皱起约束，需要关联约束的地方，全部由前台代码保证。
dobear_0922 2007-09-12
- 打赏
- 举报
严重支持钻钻，，，
子陌红尘 2007-09-12
- 打赏
- 举报
外键约束可以保障性能的完整性，而其他的业务逻辑也可以从一定程度上完成类似的功能；
反之，在某些情况下，不使用外键约束与使用外键约束，对某些业务逻辑的性能影响是很明显的。
反之，在某些情况下，不使用外键约束与使用外键约束，对某些业务逻辑的性能影响是很明显的。
子陌红尘 2007-09-12
- 打赏
- 举报
其实不然，完整性固然重要，但效率也非常重要，势必要在利用外键约束完整性与效率等因素之间寻求一个平衡点。
