Stored procedures 为什么（以及何时）使用存储过程？

可能重复：

当应该使用存储过程时，什么是合适的场景

我偶然发现了这样一个实现：几乎所有的数据操作都是由存储过程处理的，甚至最简单的INSERT/DELETE语句都是通过SP包装和使用的

那么，一般使用存储过程的理由是什么

很抱歉问了这么一个初学者的问题。

我知道两个原因：

保安

存储过程是安全的，不会受到SQL注入攻击等攻击

速度

---

存储过程有时是预编译的，这会加快执行速度。

对我来说，这与是否在编程时创建函数/方法是同一个问题

---

例如，如果需要在多个位置重复该功能，或者要多次调用该功能，则该功能应位于函数中。

它允许您在数据附近保持数据访问。我曾经在所有数据访问都存储在带有服务器端包装函数的进程中的系统中工作过。它非常干净（但没有ORM那么“酷”）

除了@Tom已经指出的原因之外，可能是最重要的原因（速度/安全性），我还想说使用存储过程的另一个很好的原因是代码重用。如果您发现自己到处都在编写相同的SQL，这通常表明它应该是一个存储过程。另外，另一个很好的原因是，它不仅允许开发人员，而且允许DBA在需要时更改/添加新的过程。

当其他系统需要访问您的数据时，您需要在数据库中提供API时，Procs将是一种允许您控制他们访问数据的内容/方式的方法

我是从企业的角度回答的。

两种类型的设计

将所有/大部分业务逻辑放在DB服务器上

将所有/大部分业务逻辑放在应用服务器上

在#1中，使用存储过程来实现应用程序逻辑，而不是使用编程语言。 在#2中，您使用编程语言来实现逻辑，并且更易于调试，并允许代码重用以及任何编程语言提供的所有其他功能

如果您是DB专家（并且您的应用程序是中小型的），请选择第一种方法，否则请选择第二种方法

---

顺便说一句，你会发现.NET应用程序使用了第一种方法，Java应用程序紧随其后。

这也是一个很好的观点。虽然我相信在大多数场景中，在数据和其他系统之间添加层是最好的方法，但我知道，由于定义了目标，有时可能不可行。我不是说使用代码调用存储过程的场景。在这种情况下，可以将相同的SQL调用包装到一个方法中。我试图将使用SQL比作编码，James比我更清楚地表达了这一点-->“使用存储过程的好理由是代码的重复使用。如果您发现自己到处都在编写同一个SQL，这通常表明它应该是一个存储过程。”不一定是从程序内部，但一般数据库维护和来自多个程序/实用程序等。