所有栏目 | 云社区 美国云服务器[国内云主机商]
你的位置:首页 > 云社区 » 正文

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

发布时间:2020-04-15 16:55:24

资讯分类:字符串  sql  拼接  喜欢  场景  并发  查询
为什么一些大公司都喜欢用字符串拼接sql?

看了回答。任何问题都不只是单纯的技术问题。讨论任何问题都应该有一个业务场景,所以造成了大家的争论。

高并发场景下确实不建议复杂sql,查询缓慢造成数据库服务器的巨大压力。

如果你的系统数据量没那么大,并发也没多少。写个复杂sql有有什么问题呢?

有些公司采取的措施是一刀切,复杂sql不能有,严禁sql嵌套循环等。一刀切带来的问题是可能不是一个问题,而为了解决所谓的问题浪费时间。我想说的是复杂sql效率不一定低,循环极少数次又有什么问题呢?最终的目的不还是为了保证查询效率吗?他们之间没有必然的关系。这种问题可以采用开发规范或者代码审核来避免。开发规范可以警示开发人员:联合查询n张表的时候需考虑性能问题,并考虑是否拆分sql。

还是那句话,脱离了业务场景讨论技术就是耍流氓。

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

我们不推荐字符串连接拼凑sql的做法?

1、拼凑的做法,尤其是sql较为复杂的时候,不便于阅读。让整个sql的逻辑更加混乱。哪部分是被查询字段,哪部分是条件,哪部分分组排序等等,不够清晰。

2、很多小白没什么经验,不懂sql注入的手段和危害,没有对用户输入参数进行有效性及合法性的验证。拼凑sql会导致系统存在风险。

3、比如有特殊原因,需要修改业务表名,那么拼装sql几乎能恶心死你,要修改的代码太多了。但如果我们严格按照模型层封装的结构去调用,就方便很多了。

拼凑sql不会有语法错误,但我们团队明令禁止这种做法,每个团队都有自己的规范。不想去评价别人的做法。

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

工作十几年了,一直是拼接sql,招人sql是最基本条件,主要看业务,应用在那个场景,人员匹配程度等。不过现在招人的时候,发现sql弱的人很多,这个还真不好评估,要是我我就选择拼接sql,没别的,符合业务和工作需求。

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

1.数据库更换时,部分数据库拼接的语法有区别,而orm框架基本做了兼容可以很方便的切换数据库。

2.互联网系统流量内容查询不能过于复杂,所以使用orm已经可以满足大部分需求。但是内部业务复杂的系统时,orm因为为了满足1,大量的共通拼接查询写法效率相对较低,很难做查询优化。所以所有的orm框架在提供对象关系管理的同时,也都提供了sql语法的支持为了满足特殊业务需求。java的mybatis比hibernate更有效率的原因就在这。python的django中的orm框架因为语言性能的原因,orm写法和sql写法对比效果更明显。orm在简单的curd上是很方便的,但是碰到复杂逻辑时,如果设计未考虑到复杂的链接,单纯使用orm就是灾难。

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

曾带过一个项目,其中一个数据接口处理,orm需要14个小时,动不动over heap. 10多年没碰代码的我,被迫上线现场改用纯sql,放数据库处理,处理时间2分钟以内。

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

据我所知,楼主提的问题是伪命题。很多项目用orm这类的中间件来处理数据模型。

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

如果系统不大,拼接方式的开要简单高效得多。至于SQL注入,通过SQL过滤等,是有方法可以避免的。

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

不得了,现在用go写,懒得用orm,拼的sql,咋办?既不会被注入,也可以方便各种切库,效率还比较高,怎么破?

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

拼接字符串,看你拼在哪里。

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

最终不都是拼接成sql字符串的么? 防止注入就自己把参数检查做到位就好了。各种框架表面好用,等查问题的时候会恶心死你。

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

哪些大公司?请举例说明

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

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

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

看了一下评论,有的偏题有的不准确,为什么拼接sql,一句话就是:为了效率。如果使用orm框架各种封装,效率显然没有直接sql来的更直接。这也是mybatis比hibernate现在更流行的一个原因。

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

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

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

拼接是难以避免的。

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

拼接的不怕被注入吗?

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

个人习惯,跟大小公司有什么关系。这么做很灵活,我就喜欢这么干。

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

了解一下sqltoy-orm,谁说大公司都拼接的

留言与评论(共有 0 条评论)
   
验证码:
Top