现在后端编写的功能代码，一个功能代码中，一般会有多少次调用 jdbc 访问数据库？

[tctc4869]

传统企业的如银行金融，他们的网络软件功能的访问数据库，听说基本是存储过程写好，程序员只需要调用一次就行了。 后来互联网企业出现了，不倡导，甚至禁止用数据库自带的组件，例如存储过程，触发器，游标一类，阿里云就是这么一个例子，既然不能用存储过程封装 sql 语句了，那么为了开发方便，就得用 orm 框架了，最开始是 hibernate，但重，学习成本高，然后是 mybatis 。但 mybatis 是半自动 orm 框架。除了封装 jdbc 大部分操作，还有管理 sql 语句模板的功能。后来的 orm 框架基本有这两个框架的影子，要么就是类似.net linq 那一套。

各位程序员们写负责功能 Controller 类代码时候，写一个接受请求的方法，各位写的请求接受代码里，所编写的编写的代码里，最多会出现多少次 jdbc 链接次数？

那么问题来了，我担心的是一个功能连数据库的次数较多，并发起来叠加会不会出现什么奇怪的问题？数据库死锁？还是其他的什么？ 编写一个功能代码，jdbc 访问数据库弄成一次，还是多次？（类似 Spring mvc 那种拦截器权限验证和用户日志记录不算），如果弄成一次，各位是写存储过程封装，还是把 sql 语句丢到类似 mybatis 框架的 sql 模板文件里？还是大家为了开发方便和规范，大部分是用类似 tk.mybatis 或者是 JPA 之类的 orm 框架，都是超过 2 次以上的多次调用 jdbc 访问数据库，只有特复杂的，才会写 sql 语句用 mybatis 管理。是这样的吗？

[gz911122]

不写存储过程,
业务需要几次调用就几次调用,纠结这个干嘛

[opengps]

各有各的场景，提倡不提倡都是有场景前提的。
银行用的起大厂正版服务，而且模式相对固定，用了存储过程可能也无妨。
企业年年都有新的方向，数据库需要简化到最原始的读写上去，靠程序来实现调度，所以提倡精简
企业比较就行采用云架构来开发，原因在于部署集群可大可小，方便及时不动代码就单纯通过运维通过机器数量配置来调节系统承载力

[hantsy]

JPA 查询可以缓存的。

[zivyou]

手边有个项目，之前为了减少查询次数，在数据库表上建立了很多关联关系，然后大量使用 join 去查询。
后来各方需求发生了变化，才理解这种设计很蠢。不仅效率低，而且难扩展。
所以现在我倾向于「宁愿多查几次」，而不是企图「查一次解决问题」

[wysnylc]

迷惑发言,一碗饭里有多少粒米?

[xiangyuecn]

select * from V2EX WITH(UPDLOCK) where t=655985

select * from V2EX where t=655985 FOR UPDATE

优雅的加个锁

[lix7]

连接都是连接池复用的，连接不够自然就排队了，不会出现你说的并发叠加什么的。而且死锁不是这个意思的。
现实情况是，该调多少就调多少，除了明显犯蠢，不用想太多。

[zunceng]

我用 mysql driver 不用 jdbc 所以是 0 次

[Rheinmetal]

存储过程的负载不一定小哦 不用它是业务性质问题 调试存储过程难度太高 银行写一次用很多年 自然可以搞 业务一个月变几次 存储过程就难受了

[timbotetsu]

@zunceng 大神👍

[zr8657]

有幸见识过 3 层 for 循环调数据库的

[l641437123]

很迷惑，连接数你有连接池来管理，看你集群的规模

[sumarker]

这个要看连接池的配置吧？

[gscoder]

互联网行业一般严禁使用存储过程

[littlewing]

你是用的短链接，每次查询新建一个数据库连接？

[ymz]

@zr8657 这个牛逼死了

[tctc4869]

如果一个功能要展示多个实体的数据在一个区域上，各位会是怎么弄呢，是写个复杂的带 join 的 sql，还是其他的方法？