@msg7086 咱俩就此打住吧，你也没有提供任何关于“被迫”二字的论据的意愿，我也不能认同你提出的“数据库外键不符合 best practice”的观点，不妨把这次谈话降级到茶余饭后的级别，不要伤了精神影响工作。Ruby 还是一门很可爱的语言，Rails 还是一个很方便的框架，权当追忆吧。

关于帝都雾霾，我记得当年我刚来帝都的时候，冬天那个冷啊，出宿舍风吹到脸上割得慌，不过那时候的天气是真的好，一片晴朗。最近这几年雾霾严重的时候，出门都感觉不到有风，冬天了也不太干燥，很奇怪，就好像西伯利亚的冷风消失了

@msg7086 “Rails 一直到 4.2 才开始（被迫）支持数据库外键，不就是因为 Rails 的团队和用户都觉得数据库外键不好用吗？如果他们都用的话，为什么这么晚才支持呢。” 谁主张谁举证，亮出你的 case

@msg7086 别杠啊，rails 04 年才发布，5 年已经是整个生命周期的三分之一了，目前 rails 的应用里 rails4 的占大头，而且 activerecord 很明显的为外键提供了一整套支持，作为同时开发和维护过 3.x 和 4.x 两个版本的 app 的人，你能很明显地感觉到从数据库层面支持外键后对复杂业务带来的开发效率提升，我觉得我这么干说不太好，我建议你试试看，最好能做实际业务的尝试。
至于是不是「硅谷创业公司的最爱」，我也能明确的告诉你，至少在 15，16 年的时候，rails4 是的，但是随着人工智能的兴起，现在应该是 Django 或者 flask 了吧，想想就难受😣

@helloworldgo 你应该也停留在挺早前的版本了，ActiveRecord::Migration 早就加入添加 foreign_key 功能了，建表时直接生成对应的 foreign_key

@msg7086 哥 9012 年了，Rails4.2 是 2014 年发布的，那时候我还没毕业

@helloworldgo activerecord

@passerbytiny 我觉得这个定论过于草率了，项目设计阶段，按照“只要有能力必须上更有扩展性 /可维护 /性能好的设计”这种定论一定是非常过度设计的，关键点在于我用了外键 /CRUD 能节省 20 人天，这些人力就可以更好地确保项目进度正常进行，减少 bug，少砍功能，让项目和公司更大可能活下来，这就是项目刚启动 /公司刚创立时的逻辑，例子就是 ROR，框架里到处都是外键的影子，但是仍然是硅谷创业公司最喜欢的框架，也是很多大厂用来实验原型的框架，为啥？可以一个人当五个人用。而如果“只要有能力必须上更有扩展性 /可维护 /性能好的设计”这个定论真的存在的话，每一个架构师 /leader 都得考虑，如果我用了低扩展性 /不好维护 /性能不好的设计来换取开发时间的话，将来项目真做成了需要性能的时候我会不会成为千古罪人呢？
说实话我还真没见过这么想的架构师 /leader，项目没成功的时候尽量先紧着进度来，项目成功了拿公司的钱重构，这基本上就是一个技术选型通用的标准，我甚至觉得这个事情没什么可以讨论的，毕竟一个用了所有扩展性 /可维护 /性能好的设计的项目，最后没做起来，也还是 nothing.

你评估过项目数据的数量级吗？评估过适用范围和业务复杂度吗？评估过公司能够投入的资源吗？用不用外键是个取舍的问题，如果项目数据量级不打，但是业务极其复杂，用外键可以大大降低设计难度，也就大大提升了开发效率，海量数据场景下不用外键是我们的共识，但是如果你的项目不是海量数据呢？过度设计是非常不好的行为，我们都该注意避免这一点

我确定第二次没过不是你的问题，你们的 TC 里怎么还有这种菜鸡选手呢？

脱离了实际场景谈技术的优劣性毫无意义，技术理应服务于业务场景，所有技术上的创新也应该围绕解决实际问题或者由实际问题抽象出的哲学问题进行，而技术本身其实毫无意义

其他都还好说，如果你认为自己的能力有问题，真的意识到了自己不适合不属于这个行业，那转行要趁早，趁年轻有时间赶紧转

@BJXY 我寻思着这个标准应该提一提，年收入 50w 的资深马仔门槛和 100w 的中层管理门槛