外键问题
数据库建表过程中，应避免外键的使用？还是...... 外键对性能有影响吗？

------解决方案--------------------
外键的主要功能就是要维护数据的一致性。如果不用外键做，你也需要在程序中实现吧。用程序做效率只会比外键低。

用外键的不好之处是：你可能需要对所有的外键字段都需要建立索引，否则锁的问题可能会非常严重（尤其是8i）。这些索引可能在查询中用不到，浪费空间
------解决方案--------------------
正方观点：
1，由数据库自身保证数据一致性，完整性，更可靠，因为程序很难100％保证数据的完整性，而用外键即使在数据库服务器当机或者出现其他问题的时候，也能够最大限度的保证数据的一致性和完整性。
eg：数据库和应用是一对多的关系，Ａ应用会维护他那部分数据的完整性，系统一变大时，增加了Ｂ应用，Ａ和Ｂ两个应用也许是不同的开发团队来做的。他们如何协调保证数据的完整性，而且一年以后如果又增加了C应用呢？ 
2，有主外键的数据库设计可以增加ER图的可读性，这点在数据库设计时非常重要。
3，外键在一定程度上说明的业务逻辑，会使设计周到具体全面

 

2009-11-11 13:08 TeDongDesiger

反方观点：
1，可以用触发器或应用程序保证数据的完整性
2，过分强调或者说使用主键／外键会平添开发难度，导致表过多等问题
3，不用外键时数据管理简单，操作方便，性能高（导入导出等操作，在insert, update, delete 数据的时候更快）
eg:在海量的数据库中想都不要去想外键，试想，一个程序每天要insert数百万条记录，当存在外键约束的时候，每次要去扫描此记录是否合格，一般还不止一个字段有外键，这样扫描的数量是成级数的增长！我的一个程序入库在3个小时做完，如果加上外键，需要28个小时！

结论：
1，在大型系统中（性能要求不高，安全要求高），使用外键；在大型系统中（性能要求高，安全自己控制），不用外键；小系统随便，最好用外键。
2，用外键要适当，不能过分追求
3，不用外键而用程序控制数据一致性和完整性时，应该写一层来保证，然后个个应用通过这个层来访问数据库


------解决方案--------------------
外键是约束，是否需要建立主要看你的系统一致性要求与其他需求的平衡点在哪里。

至于索引是否在外键建立，主要看是否根据外键查询，大部分情况是需要的，也就是说，外键建立索引并非外键引起，而是功能需求决定
------解决方案--------------------
外键应该没影响吧
建立外键看个人喜好，有的人不喜欢建物理外键，而是用程序来保持数据完整性的
------解决方案--------------------
对 外健 约束 强制数据的完整性，建议还是使用，有时由于设计与实现的冲突会放弃 外健，用程序来控制。

http://technet.microsoft.com/zh-cn/library/ms175464(SQL.90).aspx
------解决方案--------------------
个人建议尽量避免使用外键约束,

1.增加了DML语句的执行成本,而这些完全可以在前端程序里控制的.
何必非得把工作全部丢给DB端完成.

2.增加了表结构变更及数据迁移的复杂度,很是麻烦.




------解决方案--------------------

------解决方案--------------------
补充一点,
3.可能引起不必要的阻塞,例如a表b字段参考了c表d字段,向a.b插入一笔记录时,
需要去c.d判断是否存在,此时如果c.d上刚好有事务,那a.b的插入进程就被堵了.
------解决方案--------------------
设计的时候加上晚间约束，等程序写好了，就把外键给删掉。