了解存储过程的优点以及何时编写存储过程以及何时避免它们。
虽然在 2021 年谈存储过程可能看起来很奇怪，但您可能会对仍然使用存储过程的应用程序（旧版和新版）的数量感到震惊。
存储过程是一种数据库能力，它允许开发人员在数据库级别编写代码并直接操作数据（有时还定义数据，即创建表、索引、删除它们等。）
存储过程有很多优点，包括：
- 与通过另一个应用程序层进行处理相比，数据操作的高性能 ，因为跨其他层传输数据至少会引入网络延迟。
- 抽象 数据库结构和逻辑的，其中涉及抽象的所有优点。
- 易于 DDL 执行， 其他一些语言和框架对 DDL 有限制。
- 直接访问某些数据库功能，这些功能对仅执行 DML 的客户端是隐藏的。
什么时候不鼓励存储过程
但是，出于以下原因，在多层应用程序中通常不鼓励对存储过程进行编码：
- 分布式逻辑
通常，多层应用有一个业务层，承载业务逻辑，包括验证、编排、业务规则等...，使得另一层逻辑导致逻辑分布在多个层之间，违反了一致性和关注点分离
- 事务管理
这与前一点有关，但是，它更特定于事务。事务应该由单层管理，在业务层和存储过程之间分布事务会带来难以管理的负担，通常会导致意大利面条式代码和艰难的解决方法来管理提交和回滚。
何时使用存储过程
在某些情况下，存储过程可能很有用，并且被认为是完成这项工作的有力候选人
- 集成项目
在大型企业中，EAI（企业应用集成）是将不同系统集成在一起的常见做法，这通常是通过支持不同接口能力、节流、后端驱动程序、集中治理等的中间件应用程序来完成的……，这个中间件利用服务，使消费者能够从/向提供者拉取或推送数据。在这种情况下，如果服务的目标（提供者）是数据库，那么为了抽象起见，最好的做法是将查询/管理数据的任何 DML 语句包装到存储过程中。
- 公用工具
即使在多层应用程序中，存储过程也可以用作简单的实用程序，以在将数据发送回应用程序或将数据插入表之前执行一些辅助功能（例如：数据转换、准备等...），但是，应仔细考虑此选项，因为广泛使用它会再次导致分布式逻辑问题
- 以数据为中心的应用程序
一些应用程序包括数据库中表之间甚至跨数据库的批量数据操作，ETL 工具对于此类任务并不总是可用或方便，例如在对其进行一些处理后将数百万条记录从表移动到另一个表。这些操作有时更适合用存储过程处理。一个极端的情况是应用程序完全在数据库中，没有接口或根本没有接口。
- 团队能力
既然您的公司赢得了该项目，但您的大部分可用团队只具备数据库和存储过程方面的知识，您可能别无选择，只能采用这项技术来交付，但是，您必须考虑培训您的团队或带来其他资源了解未来项目的趋势技术。