别说了，一会儿又打起来了···

完，到现在不会这样吐痰，只能不停的用力咳，把痰咳出来

看了下你的附言，正确的做法大概是直接集成类 A ，自己实现一部分功能。出这种问题要么是你对这俩类的使用方法不恰当，要么就是这俩类本身封装的不好，才会让你需要做这么奇怪的事。
C++下方法可以是虚的也可以不是，Java 都是虚的就没正常办法了…

这…确定关系花十几万定亲…这怎么一种做生意签合同交定金的感觉…

@zxjunz 其实就是不太理解，如何喜欢 /利益相关能到这个程度，对于大部分程序员来说，语言应该只是个工具吧～～～

没必要，提一下是在说服不了，就努力换团队好了

总有人会选择无视自己的现实状况，盲目跟从某些大厂根据自己的实际状况制定的最佳实践，却忽视了所谓最佳实践总是有其特定上下文的

@dcoder 是啊，这一切都需要在特定的上下文中进行权衡，也就是我上文说的脱离具体上下文很难讲该如何做，性价比到底是高还是低。

@dcoder 解释一下我的上条发言，就是说有人可能不愿意学习某个特定的 DSL ，导致本来一行代码完成的内容需要他额外写一百行来实现。脱离具体的上下文很难说谁更“高效”，只不过是个人的选择而已，我所谓的“正确”也是在其中夹杂了我的个人偏见。

@dcoder 认真设计 schema 和 index 是最基本的要求，这和“正确地”使用工具并不冲突。当然这里我对“正确”的定义可能有些狭隘。

@iseki #2 最神奇的是，他直接要求删掉外键的理由是，外键耽误他无视逻辑关系的 delete 删数据了……

@dcoder 是啊，是这样啊，每个人选择不同，导致了不同的结果。

@Mac 是不是有点太过于因噎废食了…

@dcoder 哈哈这里确实见仁见智了，有人宁可自己写一大坨，跑的慢死还一堆问题，就不肯看看一句稍微“高级”那么一点的 SQL ～

@dcoder 其实真不一定符合公司和程序员利益，大多时候一句 sql 出来的东西，写一坨代码，快慢不论，能不能写对都是值得考虑的～毕竟数据库积累了这么多年不是白积累的

@dcoder 私以为这种场合没有继续强行使用支持 SQL 的关系型数据库的必要

个人支持在大部分场景下使用数据库提供的“物理外键”，和 tl 争吵的结果是，他表示可以接受脏数据，但不能接受维护时（导入导出）的麻烦～～个人保留意见