[外键应不应该建立]

[pushback]

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

[wangyanrui]

@pushback 听和 leader 关系最好的那个 = =

[dobelee]

不建议。没必要。可应用层代替。

[pushback]

@wangyanrui 啊这，那我现在潜规则 leader 来得及吗

[shuang]

上学时用过，工作后从来没用过外键

[wangyanrui]

@pushback
1.做大做强做牛批，尽量不要用外键
2. 百分之九十五的系统，最后都没有做大做强，这种情况下，用不用无所谓

另：个人不喜欢外键，但是挺喜欢用 JPA，JPA 创建关联关系时默认创建了外键，懒得填不生成外键的骚操作的注解或者改源码。导致 现在已经看淡了，只要能满足业务，都无所谓！！！

[damai0419]

主张不用。
没有并发要求还能用。有并发要求，涉及到级联操作就不可控了，级联数据量太大有可能阻塞的时间比较长。
逻辑删除数据，我认为有必要保留，数据挺宝贵的。时间过久的数据，可以归档到其他引擎的数据库里。

[Sharuru]

我们的系统是 DDD 设计，一个 Domain 里的数据靠 FK 做约束，没那么不堪。

[leoding]

一般只在 ER 设计时会进行外键标注，并创建外键索引，这样看起来关系清楚；但是在导出建库语句时会忽略掉外键，仅保留相应的外键索引。如果数据逻辑删除，对于没有后续数据分析相关场景来说，其实就是垃圾数据，而且就算有相应的数据分析场景，也应该将已“删除”的数据迁移出生产库，因为数据只会越来越多，避免占用生产环境资源。

[zuoakang]

有个小问题请教下：如果不用外键，框架自带的 ORM 模型不就发挥不了作用，那你们都是怎样查询出多张表关联的数据？
自己写 sql 还是 For 循环？

[pushback]

@leoding 中肯！受教！！

[neoblackcap]

@zuoakang 你用 ActiveRecord 那些 ORM 可能会需要外键，但是 Data Mapper 类的 ORM 一般是可以通过你自己指定映射关系的，所以不存在必须手写关联查询

[marquina]

@zuoakang 谁告诉你 ORM 依赖外键了……

[pushback]

@zuoakang 我是自己写 sql，循环连接次数太多，但是聚合数据我们一般分了层级接口，或者丢缓存

[wangyanrui]

@zuoakang 例如 JPA，覆盖 源码创建 FK 关联关系的代码就可以

FK 只是数据库层面的约束，对于 ORM 框架来说，只需要知道根据哪个字段去处理就可以，这个字段不一定非要是 FK 的呀

[est]

千万别做外键。业务的花样搞不死你。

就说一个巨常见的需求：不掉线改表。有的时候真的只能重建表结构，然后数据复制过去，然后改表名字。

如果你做了强制关联外键，恭喜发财。会遇到各种改不动

[zuoakang]

@neoblackcap 谢谢，可以理解为 orm 只是逻辑关系，并不影响表结构，只需要建立 orm 的逻辑外键吗

[pushback]

@est relation 的 createsql 放在最后能解决不

[constantine008]

@chenxytw 你说的太对了哥，之前我在电信那边呆过，用的 oracle，业务大量的用存储过程写。。

[zuoakang]

@wangyanrui 可能 django 框架和 jpa 框架的 orm 不同，我在不使用外键关联的情况下查出 2 张表的数据是这样做的：先查出第一层数据的 ID，然后根据这些 ID 获取第二层数据，方式是 in 第一层 ID 的列表。 不知道你那边的框架是怎么处理的

[wangyanrui]

@zuoakang 差不对
但是这不影响 字段使不使用外键呀，外键是一种约束
举例，x_id 这个字段，有外键约束，SQL 如下
SELECT .. FROM x WHERE id IN ( SELECT x_id WHERE field = xxx)
难道你 x_id 没有外键约束的时候，还不能写这个 SQL 了咩 （ doge ）