把业务逻辑写进存储过程是一把典型的双刃剑，历史上在 ERP/银行系统很常见，现代互联网架构则普遍回避。

优点：

  • 减少网络往返：复杂多步操作一次调用完成，数据在库内处理，不必把大量中间结果搬到应用层，对大数据量计算（批量结算、报表）性能优势明显。
  • 事务与数据一致性强：逻辑紧贴数据，天然在同一事务边界内，并发控制简单。
  • 统一复用与权限收口：多个应用/语言可复用同一逻辑；可只授存储过程执行权而不暴露表，作为安全边界。

缺点：

  • 可维护性差：SQL 方言缺乏现代工程支持——版本管理、单元测试、代码评审、IDE、重构都困难，调试体验差。
  • 厂商锁定：PL/SQL、T-SQL 互不兼容，迁移数据库等于重写业务逻辑。
  • 扩展性瓶颈：数据库是最难水平扩展的一层，把 CPU 密集的业务计算压进数据库会拖垮全系统的核心资源。
  • 分工与发布耦合：DBA 与开发的边界模糊，一次发版需要应用和库脚本严格同步，回滚复杂。
  • 业务逻辑碎片化：一部分在应用、一部分在库里，排查问题要在两处翻。

实践建议：简单 CRUD 用应用层 + ORM；数据密集、强一致、跨应用复用的核心操作（如账务结转）可保留存储过程，并纳入版本管理（Flyway/Liquibase）。追问方向：如何避免逻辑碎片化、存储过程如何做单元测试（如 pgTAP）、与"应用层 + 消息队列"方案的取舍。