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

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

    当时我好似胸有万言,但终究没用一个实在的例子回答同事,只是从结论上大侃一通,代码相对于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去预处理的数据。从接口语义表达就可知调用的目的,这样代码可读性也会有大大提高。
    那就动手改。但没想到的是问题来了。
    为了讲述问题,我简化代码,假设系统现有的存储过程如下:

    1. CREATE PROCEDURE [dbo].[GetJobs]
    2. (
    3. @PersonId int,
    4. @OrganizaitionId int
    5. )
    6. AS
    7. BEGIN
    8. SELECT JobId,JobName,JobType FROM Job WHERE PersonId = @PersonId AND OrganizaitionId = @OrganizaitionId
    9. END

    我在新的存储过程中调用它,我需要获得该person的jobs的数量,即GetJobs返回结果集的count。
    为了实现这一目的,首先想到的是使用临时表,将返回结果集存入临时表,再对其进行count(*)的计数操作:

    1. CREATE PROCEDURE [dbo].[MyProc]
    2. (
    3. @PersonId int,
    4. @OrganizaitionId int,
    5. )
    6. AS
    7. BEGIN
    8. CREATE TABLE #Temp(
    9. PersonId int,
    10. OrganizaitionId int
    11. )
    12. INSERT INTO #Temp EXEC dbo.GetJobs
    13. @PersonId = @PersonId,
    14. @ParentOrgId = @ParentOrgId
    15. SELECT COUNT(*) FROM #Temp
    16. 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的语句写一了次。
    存储过程在很多场景时有其优势,比如性能。但对于业务逻辑的通用方法,非常不推荐将其写在存储过程中,代码复用、扩展与客户端语言比,相差甚远。也许终究能实现,但代价与风险比客户端语言要高,得不偿失。
    天知道还有没有机会和那位前同事再讨论这一话题呢。
    【面试题专栏】
    24个经典的MySQL索引问题,你都遇到过哪些?
    面试官:你对JVM垃圾收集器了解吗?13连问你是否抗的住?
    Spring Cloud面试题万字解析(2020面试必备)
    面试官:你对Redis缓存了解吗?面对这11道面试题你是否有很多问号?
    2020年Java多线程与并发系列22道高频面试题解析
    2020年Java基础高频面试题汇总(1.4W字详细解析)
    全网最全Spring系列面试题129道(附答案解析)
    85道Java微服务面试题整理(助力2020面试)
    2019年面试官最喜欢问的28道ZooKeeper面试题
    2020面试还搞不懂MyBatis?看看这27道面试题!(含答案和思维导图)
    2019年常见的Linux面试题及答案解析,哪些你还不会?
    2019年常见Elasticsearch面试题答案解析
    18道kafka高频面试题哪些你还不会?(含答案和思维导图)
    2019年12道RabbitMQ高频面试题你都会了吗?(含答案解析)
    2019年Dubbo你掌握的如何?快看看这30道高频面试题!