为何我不喜欢使用存储过程

之所以有这个题目,我既不是故意吸引眼球,也不想在本文对存储过程进行教科书般论述。最近项目中遇到的存储过程问题,让我想起了去年在武汉出差时一位同事的发问:

我觉得存储过程挺好用的,为什么你不建议用?

当时我好似胸有万言,但终究没用一个实在的例子回答同事,只是从结论上大侃一通,代码相对于SQL,复用、扩展、通用性都要更强。想必同事并不信服。

现在想来,我最近正碰到的问题,算是一个可以回答同事的例子吧。

最近项目中有个新需求,需要校验一个用户是否有Job,Certification,Disclosure这三个业务数据。

翻看了代码发现,系统的用户个人页面的C#代码调用了三个存储过程,去抓取用户的Job,Certification,Disclosure数据。
我的新需求,自然需要复用这三个存储过程,否则:

若每一处都写一次抓取数据的业务逻辑代码,若业务逻辑发生变化,难以追查和维护所有读取Job,Certification,Disclosure的SQL。

如果我在C#代码中调用这已有的三个存储过程,事情本该非常快就能结束。我也是这么做的。

但code reviewer认为,我的需求中,并不需要Job,Certification,Disclosure这三个业务对象的数据。我只是需要给定用户是否有Job,Certification,Disclosure而已。所以我应将是否有无Job,Certification,Disclosure的判断逻辑写在数据库,最终通过网络从数据库传到web服务器的仅是true或false,节省网络流量,这样最好不过了。
也对。除开网络性能,从接口设计的角度讲,接口的传入和返回值,都应是你本身需要的数据,不应带有大量不需要或者需要caller去预处理的数据。从接口语义表达就可知调用的目的,这样代码可读性也会有大大提高。

那就动手改。但没想到的是问题来了。

为了讲述问题,我简化代码,假设系统现有的存储过程如下:

CREATE PROCEDURE [dbo].[GetJobs]
(
    @PersonId int,
    @OrganizaitionId int
 )
AS
BEGIN
  SELECT JobId,JobName,JobType FROM Job WHERE PersonId = @PersonId AND OrganizaitionId = @OrganizaitionId
END

我在新的存储过程中调用它,我需要获得该person的jobs的数量,即GetJobs返回结果集的count。

为了实现这一目的,首先想到的是使用临时表,将返回结果集存入临时表,再对其进行count(*)的计数操作:

CREATE PROCEDURE [dbo].[MyProc]
(
    @PersonId int,
    @OrganizaitionId int,
 )
AS
BEGIN
  CREATE TABLE #Temp(
    PersonId int,
    OrganizaitionId int
  )

  INSERT INTO #Temp EXEC dbo.GetJobs
    @PersonId = @PersonId,
    @ParentOrgId = @ParentOrgId

  SELECT COUNT(*) FROM #Temp
END

这种办法简单有效,但它存在严重的维护问题。未来如果被调用的存储过程的返回结果集字段有变动,那么MyProc中的临时表结构也需要随之变化。这是令人难以接受的。

那么将MyProc中的INSERT INTO换为SELECT INTO呢?很遗憾,答案是不行。SQL本身并不支持这种用法。

给现有存储过程GetJobsoutput参数?本例中因为GetJobs已被其他多处代码或SQL scripts调用,所以对现有现有存储过程进行改动会有不小风险。

我搜遍网络,一位MS MVP的大神的文章几乎总结了所有存储过程之间传递数据的方法: How to Share Data between Stored Procedures。他在文章中也无可奈何地说道

Keep in mind that compared to languages such as C# and Java, Transact-SQL is poorly equipped for code reuse, why solutions in T‑SQL to reuse code are clumsier.

最终我没能找到一种满意的办法,无奈之下我在新写的存储过程中将查询Jobs的语句写一了次。

存储过程在很多场景时有其优势,比如性能。但对于业务逻辑的通用方法,非常不推荐将其写在存储过程中,代码复用、扩展与客户端语言比,相差甚远。也许终究能实现,但代价与风险比客户端语言要高,得不偿失。

天知道还有没有机会和那位前同事再讨论这一话题呢。


Young的博客
个人笔记博客而已

一沙一世界,一花一天国

3 声望
0 粉丝
0 条评论
推荐阅读
Mybatis源码解析之执行SQL语句
通过调用 session.getMapper (AccountMapper.class) 所得到的 AccountMapper 是一个动态代理对象,所以执行 accountMapper.selectByPrimaryKey (1) 方法前,都会被 invoke () 拦截,先执行 invoke () 中的逻辑。

京东云开发者3阅读 780评论 1

封面图
Mysql 数据库的批量插入或更新(Upsert)
这个问题已经困扰我一段时间了,对于大量数据的插入或更新,批量操作肯定比每条记录调用一次快得多,新数据可以用 insert 批量插入,老数据可以用 replace into 批量更新。但如果不知道数据是否存在(是否有唯一k...

songofhawk2阅读 1.6k

封面图
Mybatis源码-动态SQL的实现原理
Mybatis提供了强大的动态SQL语句生成功能,以应对复杂的业务场景,本篇文章将结合Mybatis解析SQL语句的过程对Mybatis中对<if>,<where>,<foreach>等动态SQL标签的支持进行分析。

半夏之沫1阅读 1.2k

HTAP 数据库如何实现?浅析开务数据库中的列存引擎
TP 与 AP 融合的 HTAP 数据库正成为业内的发展趋势。但由于大规模数据场景下 TP 与 AP 系统本身的复杂性,要在一套数据库系统中融合两种使用场景的功能并不容易。浪潮推出的 HTAP 开务数据库(原:云溪数据库)采...

KaiwuDB阅读 2.4k

封面图
深入解析 Raft 模块在开务数据库中的优化改造(下)
开务数据库(原:云溪数据库)是由浪潮开源的一款 NewSQL 分布式数据库,具备 HTAP 特性,拥有强一致、高可用的分布式架构。其中,开务数据库各方面的强一致性都依靠 Raft 算法实现。我们在上一篇文章中介绍了 Ra...

KaiwuDB1阅读 976

封面图
【建议收藏】15755字,讲透MySQL性能优化(包含MySQL架构、存储引擎、调优工具、SQL、索引、建议等等)
Server 层:主要包括连接器、查询缓存、分析器、优化器、执行器等,所有跨存储引擎的功能都在这一层实现,比如存储过程、触发器、视图,函数等,还有一个通用的日志模块 binglog 日志模块。

紧张的羊肉串aa2阅读 392

时钟同步技术解析:原子钟实现 Ture-time 机制
在分布式数据库系统中,为了解决不同集群、节点事件发生的先后顺序问题,时钟同步至关重要。本文将为大家介绍业界现有的几种主流的时钟同步解决方案,以及分布式数据库开务数据库(原:云溪数据库)基于原子钟技...

KaiwuDB阅读 1.5k

封面图

一沙一世界,一花一天国

3 声望
0 粉丝
宣传栏