[外键应不应该建立]

不用...很坑,就算要用,也不要用级联删除...
级联删除这个东西,用的熟练,能达到[rm -rf /]的效果

听领导的，然后想要实现啥目的都去通过额外的代码去实现。

@yulitian888 打扰你了，可能我说的太跑题了。

很多年我工作中不再具体的关心数据库了，有时都是几种数据库混合，现在用单一数据库的情况反而太少，合适的场景用合适的数据库（包含 RDBMS，NoSQL 了）。

我一直主张 Java 要以 Domain 为出发点分析业务，才符合 OOP 基本特性，所以我 10 几年做的项目中，也没有所谓的数据建模这一步，也不会有所谓的数据库设计文档，因为整个开发过程根本就不用关心过数据库里面是怎么保存，怎么读取的。

@zhaishunqi 草（熟练 max 也太骚了

看到上面不少人说把旧数据迁走，那么旧数据要用到的时候怎么办？或者说什么样的旧数据可以迁？在我做过的项目里似乎能迁的旧数据少之又少

我司禁止用外键

这个决策看具体场景的，我的经验是：
- 需求 /数据模型不确定，或变化很快的，或约束弱的，不用。
- 对脏数据敏感度低，但是对接口报错敏感度高的，不用。（典型的互联网场景）
- 单表数据量极大的，不用。
- 对脏数据敏感度高的，用。
- 表的数量很多，但表都不大的，用。
- 其他可用可不用。

楼主的伪删除需求我觉得对用不用外键影响不大。伪删除的目的就是永久保存吧，只不过可以保存在别的地方。

以前我贱，现在我不贱了。

@pushback 我们的做法是用外键的，而且数据库接受源码管理。这一点再 Oracle 和 SqlServer 上做的比较好，使用 VS 有成熟的项目支持，Mysql 就比较难受了，需要自己写。
通过源代码管理，可以看到数据库发展的脉络，通过数据库的关系可以直接导出关系图。
每次迭代发布，SQL 脚本项目是可以自动生成增量包的，所以发布过程永远是源码到示例的单向运动，开发者只需要对源码负责，没有外键的话是不可想象的。一来人脑无法顾及到每一个细节，二来自动生成增量包的时候以外键为依据会进行适当的检查生成正确的增量发布脚本。

开发环境可以加上外键进行开发,保证数据的有效性
生产环境建议把外键删了,影响性能

外键这么好用的东西怎么能不用, 长期撸企业项目, 外键起着非常关键的作用, 数据的完整性, 约束, 级联删除怎么用怎么爽, 外键的使用当然也讲技巧, 数据量大的表,日志型的表 避开就行. 性能问题真没遇到过,可能最大数据量也没过千万的原因吧. 互联网项目弄的少,也许是该少用外键吧.

@chenxytw 我们公司的存储过程估计没有几个人看得懂，重构都麻烦

DBA 不让用

禁存储过程，禁外键

读书时，老师介绍外键。我觉得这是一个牛逼的设计。DB 竟然可以做到 言行一致。
出来工作后，我发现外键是个累赘。基本公司都不要求搞外键。可恶的是 DB 很多事情，前同事用了，他离职后，一坨屎等着我去捡。。

最佳性能角度：建立外键，自动删除，迁移过期数据；

高开发效率：建立外键，自动删除，新旧数据同时存放；

高安全：不建立外键（防止 CASCADE 自动删除），禁止账号删除权限(只做软删除)，新旧数据同时存放；

如果你是领导，你选哪个方案？
我选择 3，只在需要时候才迁移无效数据作为补充。

还有一点考虑是你用的 ORM 是不是能正确处理这个东西。比如 @yulitian888 所提到的这些：生成增量包，通过数据库关系导出关系图，这些东西在我们写 Rails 的时候就一点用都没有，因为我们的 ORM 早已自带了这些东西，数据模型关系就在 model 上，直接就能导出关系图，增量包的话 migration 本来就是编写增量包源码，所以外键对他们的项目来说非常有用，而对我们的项目来说没有任何卯月。

我相信上面讨论的人也有这些情况，有些人用了功能完备的 ORM，所以哪里需要用到什么外键啊。另一些人对着数据库就是一阵手撸，说不定建表还是 phpMyAdmin 建的，对这些人来说外键的作用就会大很多。

@encro 如果我是领导，我会让他们老老实实 ORM 处理，既高性能，又高开发效率，还安全。小孩子才做选择，大人全都要。

@msg7086

正因为可以 orm，所以选 3 。。。

@zuoakang 我们当时手写 sql 建表，改表结构，但是在 Django 的 orm 里面还是可以写外键关系的，数据库并没有建外键约束