想跟大家讨论下，数据库建表是否需要建立外键约束

最近做项目的时候在讨论表与表之间的关系是否需要建立外键约束，
下面是我总结的一些优缺点，欢迎大家指导，帮忙分析一下到底使用哪种方式

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

我们公司一直都这样   一律不用数据库外键。
所有外键逻辑都用程序来保证

谢谢

如果你不需要参照完整性（数据不完整也没关系，或者不可能不完整，其他机制保证了）
或者无法使用参照完整性（比如分表/分库）
或者有其他机制保证参照完整性（比如在应用中搞定）
或者参照完整性影响性能（大批量数据插入）
那就没必要使用。否则，根据自己的需要考虑使用，我做项目中不使用外键也不没遇到严重的问题。个人观点，多多指正

哎，我也一直在纠结这个问题，
不过目前做的几个系统都是使用的外键。
还有，外键导入数据的时候，比较麻烦，例如excel数据的导入。

想在程序逻辑偷懒的人才用外键约束

导入数据时禁用外键即可 有命令

如用程序对数据的完整性约束代替数据的外键约束，是否增加了程序的复杂性，导致程序无法安于业务层面的开发？

PS：个人愚见^_^

程序约束可以做到很友好的错误提示
DB约束想做友好提示就不那么好整了

外键不错啊，可以用，只不过，很多时候会有想死的心