先表明立场，任何时候都不要在后台代码里拼接sql。(除了中小公司内部报表类需求外)
首先，提主遇到的大公司拼接sql，“都”明显是伪命题。在互联网公司的应用领域内，是严禁嵌套，拼接sql的。一个大流量超高并发的系统，数据库链接池资源，是非常宝贵的。基本决定了系统的性能上限。不然为什么加分布式缓存，数据库分库分表呢？对于高频低熵的系统，明显高频次低耗时的数据库链接是最可靠的方式。
其次，对于各种大型的传统IT服务业和政府，银行类系统，由于系统本身相对于一线互联网公司，并发非常低。所以线程对数据库链接的持有时间可以稍微耗时长一些，以得到比较快的系统响应。其实这么做，也并非是明智之举。明显，互联网类的技术拆分和技术架构，对于大公司的各种场景更为合适。传统的IT那种所有难题扔sql，扔给存储过程的方式已经过时多年。
最后，对于高并发的大型在线系统，有复杂查询类的需求，绝不推荐在后台sql中用复杂的查询去实现。这个对于系统的成本消耗明显太高。对于复杂的查询，自然有其他的技术架构去实现。
可以多多关注一线互联网公司的架构技术，也可以看下我之前的回答。
发现持续还有人关注本问题，看到大家来自各个不同业务领域，再聊一些吧。
本身这个问题是高并发类系统的常识性问题。不管是低频高熵的传统业务，还是高频低熵的互联网业务公司，技术架构往往是业务特性来决定的。
传统IT公司，IT服务类公司确实仍然存在拼接这样粗暴的实现方式。因为并发低，迭代快。当然如果能满足低频低熵的业务需求，也无可厚非。但单单从技术角度看，这么做可能并不是最优。事实上，传统公司的新项目也很少有人会这么玩了。(节省几台服务器，也是钱啊)。
很多同学领域不同，对业务需要的技术理解自然会有区别。技术同学可以适当多看机会，多接触不同业务领域的技术实现方案。多思考技术架构这样设计背后的业务原因。
另外，如果有任何问题或质疑，欢迎去看我之前的回答，或留言与我讨论。不喜勿喷。
评论0
加载中...
题主说的确实存在，但是要区分不同业务类型和领域的“大”公司，软件行业里面，有bat这样的互联网公司，也有神州这样的看起来大的公司，也有蓝凌这样的专做OA的大公司，还有思迅这样在收银软件独霸一方的。他们在各自领域，都是大公司。
如果是传统管理软件的公司，这种情况确实大量存在。这和历史原因，业务现状有关。他们的主要问题是每天面临大量不同项目的不同功能需求要完成，当合理的使用拼接sql方式，能够加快开发交付速度，也能灵活面对业务需求的变化。这类软件的业务复杂度远大于并发需求，所以这样也能抗住性能压力，也能完成各种复杂功能（业务复杂{{BANNED}}程度远超一般长期接触互联网行业的工程师的想象）的快速开发。
而如果是一个互联网公司，业务又是2C的，那么就不会拼接sql了。往往采用基础表的数据整条读写访问（数据库沦为持久化工具之一），数据内存做缓存，数据逻辑关系由代码而不是sql完成，以提高效能，降低延迟，提高并发（按每秒单节点10w次记）。所以，这种大公司是绝不可能大量有sql拼接的，有也是少数sql，也或许是缓存穿透后的操作。
还有一种情况，就是大公司里面某些团队，接了开发任务，项目又是项目产品型的，项目负责人开始为了加快进度，搭建的基础架构就偏简单，加之业务还没成熟，技术选择上也会采用拼接sql来实现，这样对开发人员要求低，开发速度快。
综上所属，就会出现，题主说的情况，那些说没有的人，也没错，他们只是单一行业接触的多，跨行业领域接触的少而已。
评论0
加载中...
看了回答。任何问题都不只是单纯的技术问题。讨论任何问题都应该有一个业务场景，所以造成了大家的争论。
高并发场景下确实不建议复杂sql，查询缓慢造成数据库服务器的巨大压力。
如果你的系统数据量没那么大，并发也没多少。写个复杂sql有有什么问题呢？
有些公司采取的措施是一刀切，复杂sql不能有，严禁sql嵌套循环等。一刀切带来的问题是可能不是一个问题，而为了解决所谓的问题浪费时间。我想说的是复杂sql效率不一定低，循环极少数次又有什么问题呢？最终的目的不还是为了保证查询效率吗？他们之间没有必然的关系。这种问题可以采用开发规范或者代码审核来避免。开发规范可以警示开发人员:联合查询n张表的时候需考虑性能问题，并考虑是否拆分sql。
还是那句话，脱离了业务场景讨论技术就是耍流氓。
评论0
加载中...
看了一下评论，有的偏题有的不准确，为什么拼接sql，一句话就是：为了效率。如果使用orm框架各种封装，效率显然没有直接sql来的更直接。这也是mybatis比hibernate现在更流行的一个原因。
评论0
加载中...
1.数据库更换时，部分数据库拼接的语法有区别，而orm框架基本做了兼容可以很方便的切换数据库。
2.互联网系统流量内容查询不能过于复杂，所以使用orm已经可以满足大部分需求。但是内部业务复杂的系统时，orm因为为了满足1，大量的共通拼接查询写法效率相对较低，很难做查询优化。所以所有的orm框架在提供对象关系管理的同时，也都提供了sql语法的支持为了满足特殊业务需求。java的mybatis比hibernate更有效率的原因就在这。python的django中的orm框架因为语言性能的原因，orm写法和sql写法对比效果更明显。orm在简单的curd上是很方便的，但是碰到复杂逻辑时，如果设计未考虑到复杂的链接，单纯使用orm就是灾难。
评论0
加载中...
曾带过一个项目，其中一个数据接口处理，orm需要14个小时，动不动over heap. 10多年没碰代码的我，被迫上线现场改用纯sql,放数据库处理，处理时间2分钟以内。
评论0
加载中...0
回答0
回答0
回答1
回答0
回答0
回答0
回答0
回答0
回答0
回答
