[外键应不应该建立]

[pushback]

和 manager 讨论外键应不应该建立，意见有点不一致
应用表是在 relation 上
对应外键在 user 及 resource 表内
因为整个公司项目都是伪删除，他主张不建立
但是我想着如果时间过长，太久没删除的数据会导致数据量越来越庞大，想使用 CASCADE 一并删除部分超过 3 年的数据🤦‍♀️
这里还涉及到伪删的数据是否要永久性保存
各位 v2er 给个意见

[wangyanrui]

@zuoakang 外键是约束，表示字段必须满足一定的规则，并不是说没有这个约束规则就不能连表查询

[jaylee4869]

2020 年：不要用。

[purensong]

建议原地离职，听留下你的那个 leader

[wysnylc]

不要使用外键,想想以后业务复杂,删除一个数据要联动十几张表就太恐怖了

[Joyboo]

外键不建议使用哦亲，坑很深

[yulitian888]

应该建
不建外键为什么要选关系型数据库？
选关系型数据库并果断放弃它的优点，什么思路？
千万别提性能，千万别提互联网，一整个库里找不出一个适合用外键的场合，是什么样的业务？只要单反有一处两处需要用到外键的场合，凭什么就把外键打的万劫不复以彰显自己反范式的功力？

[chinvo]

@Joyboo #44 有哪些坑，虚心求教，亲

[ZX576]

不建议用，维护起来太难受了

[lionseun]

关注帖子起来了

[pomelotea2009]

旧数据用定时批量转移就可以，不要占用负载去实时处理

[WhoMercy]

根据业务来吧，有足够经验能衡量利弊时（复杂度，安全性，开发、运行效率的取舍）再选择上不上。

如果缺少做决策的人，或者经验不足衡量不了，建议按最简原则来施行。

更高的要求是在你们有足够经验或者目标明确的情况下，自然而然的过渡，不要过度设计。

---

以我的观察，现在网上的论调大多是不建议使用，这无可厚非：
因为现在互联网环境提倡快速迭代开发，而不是早年软件工程那一套需要开发后持续长期稳定维护更新的工作流程，所以各种范式约束反而会成为累赘。

---

但也不是说软件工程、范式那一套就没用，只是说需要用的人基本都可以自己确认，来问的大多是不需要用的，做决策者心里要有一把尺。

[hantsy]

@yulitian888 任何东西没有绝对的。

反范式的设计有时避免不了，JPA 继承的 JOINED 策略也违反数据库设计范式。以前在企业用户开发时，我特别喜欢全部建立数据外键关联关系，因为用一些 Stateful 的框架，比如，我用了两年 JBoss Seam，可以自行调节 FlushMode，跑一个 Conversation，跨多个页面，读取关联数据完全不用担心 Lazy Load 的问题，保存关联对象也很容易。但是到了一些 Stateless 的框架，比如当时的 SpringMVC，数据跑到 View 层，必须开启 View In Session 或者在进入 View 之前转换，各种关联在页面太令人头痛。Spring WebFlow 为了对抗 Seam，火了一段时间，现在这个项目也没在更新了。

DDD 中 BoundedContext 处理跨 Domain 的关联问题用一种比较折中的方式，比如用一个 Ref 类来记录 Order 中 Customer，即 CustomerRef （仅包括一个 ID 等唯一标志，对应到 Order 表就是记录一个 CUSTID，但不建立外键关联），Order，Customer 两个不同的 Domain 有自己生命周期，互不干扰。但 OrderLineItem 与 Order 是存在同一个生命周期内的，前者不能孤立存在，他们在表结构是外键关联。

[love]

别问了，象我这种曾经求完美外键派现在都打死不用外键了，真是有百害只有微利。

你说的外键可以一键删除所有关联对象的好处，没外键又不是不能删除，还可以分批删除而不是在一个巨大事务中一次删除。

[love]

@yulitian888 审题错误，LZ 是指要不要建外键时用上数据库内置的外键约束功能，而不是要不要外键，关系数据库当然是要用外键的，又不是 NOSQL

[kanepan19]

从业 10 年，没建过外键
狗头保命

[yulitian888]

@hantsy 所以你想说什么？
不要建--适当建--必须建，这三者之中，一头一尾是你所谓的"绝对"。我站是哪儿的，你再读一遍？
不建外键是反范式，但是反范式不是不建外键；
有人（还挺多的）靠不建外键来炫耀自己有反范式的能力，不代表使用反范式的设计都是在炫耀。
所以你说的和我说的，完全错开频道了好吧！

@love 楼主说的是，他们经理因为伪删除原因而“主张不建立”，这显然指的是不建外键，而不是再说级联选项。楼主的意图是在使用外键的同时使用级联选项，哪里读错了？
难道你认为我说的“关系型的优点”就是级联？

平心而论，国内的文档水平是什么层次大家都清楚的吧！国内人员流动率高低如何大家也都心知肚明的吧？我就说一个大家都司空见惯的场景吧：
某人新入了一个团队 /公司 /项目组，接手了别人一个库，数百张没有关系的表，没文档，甚至表名还有可能是汉语拼音缩写，只有团队里为数不多的“老师傅”才知道每个表是干什么的——这时候唯一能做的事情就是花上巨大的时间消耗，通过观看生产数据，脑补，重构关系，对不对？
要是有外键，何苦来载？
嗯，然后自己也不建外键，把这份痛苦留下后一波接盘的吧！
其实上面也有人说，互联网项目不喜欢用外键，其实原因根本不是什么性能啊——有谁是在发现了性能不够之后删除外键来改善的吗？才没有呢，都是从一开始就不建的。为嘛啊？因为互联网项目迭代快，死的也快，上面举例那种场景不构成痛点罢了！

[we6100]

DBA 角度是不允许建的，如果没 DBA 当我没说

[mingl0280]

@we6100 你这是哪门子的 DBA?

[qloog]

不要加，仅把 db 当存储，逻辑操作用程序处理。

[laminux29]

1.外键的目的是保护数据，减少脏数据。

2.不用外键，也能达到这个目的，方法有很多。比如在后端代码里处理，或者在中间件里处理。

3.个人开发或研究，在前期数据了不大的情况下，为了快捷方便，可以使用外键，来提高开发或研究速度。

4.团队协作，或者个人开发但数据量大，不建议用外键。