@Rocketer #54

我还是不明白，为什么“需求不明确”就开始开工了？就不建议使用外键了？

你说的分布式数据库指的是 NoSQL 数据库吗？

@zjsxwc #40 是有一点道理，不过要保证 referential integrity，也只有数据库外键才能做到。

@gBurnX #37 同意

@zjsxwc #24 个人感觉，这个是设计的问题，不是外键的问题，不在部门表存储负责人就行了，使用关系表解决。想象一下，把三个实体当作 Spring 中的 service 的话，它们也会造成循环依赖。

@alamaya #29 这样子的话，你也无法达到数据库外键所能实现的效果，应用代码还复杂多了。

@wqtacc #27 那怎么解决#15 所描述的问题？再激进一点的话，那还要事务干嘛，直接应用层解决不行吗？干嘛让数据库做这么多事情来保证 AID ？

@zjsxwc #20 关于“ 外键循环死锁依赖”，可以举个简单的例子吗？

@alamaya #19 应用层实现逻辑外键的话，比如我回复主题的时候需要检查主题是否存在，应用层检查难道不会给数据库增加压力？

@Jooooooooo #8 大项目用会有什么问题？顺便问一下，怎样的才是大项目？

@agagega #5 我更想知道现象背后的原因，而不是现在是怎样一个现象，欢迎分享你的想法。

@wangbenjun5 #12 “方便”具体指的是什么？

@xstmjh #10

What if someone deletes the parent while you're inserting children? Right now when I submit "add comment" -- if you have already deleted your answer, this comment is now an orphan. FKs would've prevented it.

Precisely -- it should be the DB's job, since it's the only one that can guarantee transactionality in the face of multiple concurrent clients.

不在数据库层面加上外键约束的话，应用代码怎么能做到数据库外键的效果？就比如第一段文字所描述的场景。

@ragnaroks #7 外键会带来数据库层面上的负担，难道“ 插入数据之前先检查各种冲突”就不是负担吗？

@Huelse #4 外键“ 增加了理解成本、后期维护成本”？为什么？

@ltfree #3 改需求跟外键有什么关系？

@maplerecall #8 可以具体描述一下“ 很容易造成操作放大，增加服务器负担，而且十分不利于水平扩展”吗？

@l00t #117 可以的话，把表结构发出来一下

id 是没有业务含义的，而 name 是有业务含义的。