您现在的位置: 首页 > 网站导航收录 > 百科知识百科知识

为什么一些大公司都喜欢用字符串拼接sql？

业务,互联网,大公司为什么一些大公司都喜欢用字符串拼接sql？

发布时间：2020-12-06加入收藏来源：互联网点击：

为什么一些大公司都喜欢用字符串拼接sql？

回答于 2019-09-11 08:43:50

回答于 2019-09-11 08:43:50

先表明立场，任何时候都不要在后台代码里拼接sql。(除了中小公司内部报表类需求外)

首先，提主遇到的大公司拼接sql，“都”明显是伪命题。在互联网公司的应用领域内，是严禁嵌套，拼接sql的。一个大流量超高并发的系统，数据库链接池资源，是非常宝贵的。基本决定了系统的性能上限。不然为什么加分布式缓存，数据库分库分表呢？对于高频低熵的系统，明显高频次低耗时的数据库链接是最可靠的方式。

其次，对于各种大型的传统IT服务业和政府，银行类系统，由于系统本身相对于一线互联网公司，并发非常低。所以线程对数据库链接的持有时间可以稍微耗时长一些，以得到比较快的系统响应。其实这么做，也并非是明智之举。明显，互联网类的技术拆分和技术架构，对于大公司的各种场景更为合适。传统的IT那种所有难题扔sql，扔给存储过程的方式已经过时多年。

最后，对于高并发的大型在线系统，有复杂查询类的需求，绝不推荐在后台sql中用复杂的查询去实现。这个对于系统的成本消耗明显太高。对于复杂的查询，自然有其他的技术架构去实现。

可以多多关注一线互联网公司的架构技术，也可以看下我之前的回答。

---

发现持续还有人关注本问题，看到大家来自各个不同业务领域，再聊一些吧。

本身这个问题是高并发类系统的常识性问题。不管是低频高熵的传统业务，还是高频低熵的互联网业务公司，技术架构往往是业务特性来决定的。

传统IT公司，IT服务类公司确实仍然存在拼接这样粗暴的实现方式。因为并发低，迭代快。当然如果能满足低频低熵的业务需求，也无可厚非。但单单从技术角度看，这么做可能并不是最优。事实上，传统公司的新项目也很少有人会这么玩了。(节省几台服务器，也是钱啊)。

很多同学领域不同，对业务需要的技术理解自然会有区别。技术同学可以适当多看机会，多接触不同业务领域的技术实现方案。多思考技术架构这样设计背后的业务原因。

另外，如果有任何问题或质疑，欢迎去看我之前的回答，或留言与我讨论。不喜勿喷。

回答于 2019-09-11 08:43:50

题主说的确实存在，但是要区分不同业务类型和领域的“大”公司，软件行业里面，有bat这样的互联网公司，也有神州这样的看起来大的公司，也有蓝凌这样的专做OA的大公司，还有思迅这样在收银软件独霸一方的。他们在各自领域，都是大公司。

如果是传统管理软件的公司，这种情况确实大量存在。这和历史原因，业务现状有关。他们的主要问题是每天面临大量不同项目的不同功能需求要完成，当合理的使用拼接sql方式，能够加快开发交付速度，也能灵活面对业务需求的变化。这类软件的业务复杂度远大于并发需求，所以这样也能抗住性能压力，也能完成各种复杂功能（业务复杂变态程度远超一般长期接触互联网行业的工程师的想象）的快速开发。

而如果是一个互联网公司，业务又是2C的，那么就不会拼接sql了。往往采用基础表的数据整条读写访问（数据库沦为持久化工具之一），数据内存做缓存，数据逻辑关系由代码而不是sql完成，以提高效能，降低延迟，提高并发（按每秒单节点10w次记）。所以，这种大公司是绝不可能大量有sql拼接的，有也是少数sql，也或许是缓存穿透后的操作。

还有一种情况，就是大公司里面某些团队，接了开发任务，项目又是项目产品型的，项目负责人开始为了加快进度，搭建的基础架构就偏简单，加之业务还没成熟，技术选择上也会采用拼接sql来实现，这样对开发人员要求低，开发速度快。

综上所属，就会出现，题主说的情况，那些说没有的人，也没错，他们只是单一行业接触的多，跨行业领域接触的少而已。

回答于 2019-09-11 08:43:50

这跟大小公司无关，一方面跟业务有关，一方面跟程序员个人有关，比如复杂的多条件查询，不拼接怎么办？

回答于 2019-09-11 08:43:50

不拼接你想怎么写，那些框架组件不也是帮你实现拼接的。只不过不要直接把参数拼接进去，用参数绑定处理。

回答于 2019-09-11 08:43:50

拼接是难以避免的。

回答于 2019-09-11 08:43:50

 1/3    1 2 3 下一页 尾页