后端代码处理业务和sql处理业务的抉择

转载：https://blog.csdn.net/weixin_45203607/article/details/120252073

语言不限(java c# go …)

数据库(关系型数据库)不限(mysql PostgreSQL mongodb oracle…)

下面我就以java 和mysql来讲解 使用sql语句处理业务代码 和使用java处理业务的区别 (其他语言和数据库都一样)

在互联网公司开发，看到了最大的不同就是后台代码算法比较多，模块服务化，很多逻辑都写在了后台代码中，比如各种计算甚至连诸如分组排序这种SQL最擅长的功能。

到底逻辑是应该写在后台程序中还是SQL中？这个话题其实没少讨论过

查询效率

使用sql处理业务数据,的确,速度会比使用java处理要快些.但是这只是相对的,

因为很多公司一个项目就一个数据库 不要抬杠(dev uat prod) 只能算是一个,那么你将所有业务逻辑代码都使用sql解决了.

会造成数据库压力超级大,随着用户不断的增加,就会造成提前分库分表,导致开销暴增,

如果很多个请求同时发起，然后数据库只能一条一条的处理，导致反应速度慢，如果再狠点，那就数据库崩掉了。

如果使用java来处理业务逻辑利用微服务的特点进行负载均衡那么就能将压力减少到最低

修改需求

如果业务代码基本都使用sql解决了那么就会造成sql语句少则,几十行多则上百上千行,如果是面向甲方开发的公司那么就完蛋了.

因为面向甲方开发的公司,一般需求更换特别频繁,这样就导致sql语句特别难以维护.

来看看下面的sql先别管规不规范,你第一眼看去是不是有点头疼.

SELECT tb.*,( tb.`自由行签约单数` + tb.`跟团签约单数` + tb.`签证签约单数` ) 总签约数 
FROM
	(
	SELECT
		d.counselor_id,
		d.user_name,
		IFNULL( a.自由行签约单数, 0 )自由行签约单数,
		IFNULL( a.自由行成单金额, 0 )自由行成单金额,
		IFNULL( b.跟团签约单数, 0 )跟团签约单数,
		IFNULL( b.跟团成单金额, 0 )跟团成单金额,
		IFNULL( c.签证签约单数, 0 )签证签约单数,
		IFNULL( e.自由行出行单数, 0 )自由行出行单数,
		IFNULL( f.跟团出行单数, 0 )跟团出行单数 
	FROM
		( SELECT DISTINCT cl.counselor_id, us.user_name FROM sys_client cl LEFT JOIN sys_user us ON cl.counselor_id = us.user_id ) d
		LEFT JOIN (
		SELECT
			fr.counselor_id,
			count( fr.free_id ) 自由行签约单数,
			sum( fr.deal_price )自由行成单金额 
		FROM
			sys_free_inquiry fr 
		WHERE
			fr.success_time >= '2019-07-01' 
			AND fr.success_time <= '2019-07-31' 
		GROUP BY
			fr.counselor_id 
		) a ON d.counselor_id = a.counselor_id
		LEFT JOIN (
		SELECT
			fr.counselor_id,
			count( fr.inquiry_id ) 跟团签约单数,
			sum( fr.deal_price )跟团成单金额 
		FROM
			sys_team_inquiry fr 
		WHERE
			fr.success_time >= '2019-07-01' 
			AND fr.success_time <= '2019-07-31' 
		GROUP BY
			fr.counselor_id 
		) b ON d.counselor_id = b.counselor_id
		LEFT JOIN (
		SELECT
			fr.counselor_id,
			count( fr.visa_id ) 签证签约单数 
		FROM
			sys_visa fr 
		WHERE
			fr.success_time >= '2019-07-01' 
			AND fr.success_time <= '2019-07-31' 
		GROUP BY
			fr.counselor_id 
		) c ON d.counselor_id = c.counselor_id
		LEFT JOIN (
		SELECT
			fr.counselor_id,
			count( fr.free_id ) 自由行出行单数 
		FROM
			sys_free_inquiry fr 
		WHERE
			fr.start_date >= '2019-07-01' 
			AND fr.start_date <= '2019-07-31' 
		GROUP BY
			fr.counselor_id 
		) e ON d.counselor_id = e.counselor_id
		LEFT JOIN (
		SELECT
			fr.counselor_id,
			count( fr.inquiry_id ) 跟团出行单数 
		FROM
			sys_team_inquiry fr
			LEFT JOIN sys_team tm ON fr.team_number = tm.team_number 
		WHERE
			tm.start_date >= '2019-07-01' 
			AND tm.start_date <= '2019-07-31' 
		GROUP BY
			fr.counselor_id 
		) f ON d.counselor_id = f.counselor_id 
	ORDER BY
	d.counselor_id 
	) tb

这个只是我见到的比较简单的了而且,还没有加一些偏僻的函数以及CASE

如果甲方让你修改需求的话你会怎么改???, 是不是有种无从下手的感觉,

还有一些sql语句很长的,都应用在很多接口中(也就是统称,一条sql语句解决所有业务 -sql最高境界)

如果你改了长sql某一个地方就可能导致整个系统完蛋,或者其他某个接口查询不到想要的结果…

扩展性

因为使用sql解决业务代码 ,导致数据库压力暴增,随时就可能崩溃,这时候就不得不进行数据库扩展

但是(水平切割和垂直切割)不可能无限扩展把,占用和耗费的资源是非常非常昂贵的,而且管理起来也非常费劲,而且还需要定义分割规则

如果只是垂直分割还好说 如果是水平分割…呵呵明白的都懂.

最重要的是后端的全部dao层逻辑基本都要重写, 后面就不用多说了都是泪…没有几个月呵呵,就算改好了,后期测试也是需要很久的,

如果是非常老的项目…

移值性

是数据库好移值 , 还是微服务服务好移值,都懂

以上问题的解决办法

在项目初期定义一套规范.要求开发人员不能在数据库中处理特别复杂的逻辑,

聚合函数 , 分组, 多表查询, 排序 除外,因为这些是数据库的强项,使用java处理就太费劲了 尽量少使用case IF … 能使用java解决的尽量在业务层解决

sql语句不要写的太复杂,必须能一眼能看出来是干了啥,而不是凑了半天,都不知道是干的是啥东西,

这个没有一定的标准,因为业务的原因,需要现场设计,哪些数据需要在数据库处理,哪些数据是在java业务层处理,

最后上传代码前一定要严格把关,坚持一段时间后项目的这个模式就稳定了,你好我好大家都好…