[外键应不应该建立]

[pushback]

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

[pushback]

欢迎横向讨论🙆‍♀️

[B1ankCat]

三年前的放到其他库里

[luckyrayyy]

老数据迁移走得了。我觉得外键少用，用外键相当于各种关联处理让数据库去做了，不可控。

[pushback]

@B1ankCat @luckyrayyy 那每隔一定时间就要迁移？用户已经标明删除了，这些数据还能使用吗？这里的 resource 是指用户的一些标签🙋‍♀️，这些东西怎么拿出来重复使用喃。。

[Jooooooooo]

不要建

完全没必要

你说的脏数据用另外的方案去删

[mtrec]

如果只是怕不用的旧数据影响性能的话 定期迁移出去就好了 要不要删主要是看数据之后有没有用 而加外键是挺影响性能的 我个人喜欢在业务逻辑中处理

[Ariver]

不要。

[pushback]

@Jooooooooo 因为现在需求要扩展 tag 表到文章的 tag 上，这中间还有个 relation，我想图方便，一删即删🙋‍♀️

[wangyanrui]

听领导的（ doge ）

[volCan0]

代码里控制吧，外键用不好会出问题，谁都不想背锅，理解一下

[hantsy]

可以用 Domain 之间关系强弱来区分吧。用 DDD 来分析系统 ，系统 Domain 对象一部分为持久存储，一部分临时的。那持久那部分就会最终影响到数据库的关系（如果用关系数据库的话）。

如果从 DDD 设计的角度看，如果 Domain 模型也按这样划分，将一个 Bounded Context 以的 Domain 关系为强关联，不同的 Context 之间用 Ref 不用强制关联。

一个设计上考量，划分 BoundedContext 时，看一个核心 Domain 对象（ DDD 中的 AggregateRoot ）的 [ [生命周期] ] 依赖关系，比如 Customer，Order 位于不同的 Context，但是 Order 会记录 Customer，用 Ref （ Context Map ）而不用强关联，而 Order 内的 OrderLine 等依赖一个具体的 OrderID，全部强关联。

[chenxytw]

据我所知，
1.互联网出身的不喜欢 db 层面的逻辑，纯当存数据。偏好 mysql 。
2.企业服务应用的喜欢在 db 层面搞，还有专门的存储过程开发。偏好 oracle，SQLserver 。
前者不建议，后者建议（逃，，，

[pushback]

@volCan0 啊？背锅啊，那算了（顺从）

[pushback]

@hantsy 受教受教 ，俺去恶补一下数据库设计知识了🙇‍♀️

[pigspy]

如果系统没有经过良好设计的话，最好别弄外键

[pushback]

@chenxytw 主要逆向模型比较好看（不想写 UML ）

[pushback]

@wangyanrui leader 说你们讨论一下🙃

[wangkun025]

做 web 的一直用外键，瑟瑟发抖

[pushback]

@mtrec 影响性能是更新索引吗🙋‍♀️

[pushback]

@pigspy 现在就是在讨论设计= =