可能重复:
What are the pros and cons to keeping SQL in Stored Procs versus Code
应该使用存储过程时适合的场景是什么?
我偶然发现了几乎整个数据操作都是由存储过程处理的实现,甚至最简单的INSERT / DELETE语句都是通过SP包装和使用的。
那么,一般使用存储过程的理由是什么?
很抱歉这样的初学者问题..
答案 0 :(得分:4)
除了@Tom已经指出哪些可能是最重要的(速度/安全性)的原因,我还要说使用存储过程的另一个好理由是代码重用。如果您发现自己在整个地方编写相同的SQL,通常表明它应该是一个存储过程。另外,另一个很好的理由是它不仅允许开发人员,而且DBA还可以根据需要更改/添加新程序。
答案 1 :(得分:3)
我知道的两个原因:
存储过程可防止SQL注入攻击等攻击
存储过程有时会进行预编译,从而加快执行速度。
答案 2 :(得分:1)
对我来说,这与在编程时是否创建函数/方法是一样的问题。
例如,如果需要在许多地方重复该功能,或者不止一次地调用该功能,那么它应该在一个函数中。
答案 3 :(得分:1)
它允许您在数据附近保持数据访问。我曾在系统中工作,所有数据访问都是使用服务器端包装函数存储过程。这很干净(但不像ORM那样“酷”)
答案 4 :(得分:1)
当其他系统需要访问您的数据并且您需要在数据库中提供API时 - Procs将是一种允许您控制他们访问它的方式/方式的方法。
我正在从企业的角度回答。
答案 5 :(得分:0)
两种类型的设计,
在#1中,您使用存储过程来实现应用程序逻辑而不是编程语言。 在#2中,您使用编程语言来实现逻辑,并且更容易调试并允许代码重用以及任何编程语言提供的所有其他功能。
如果您是数据库大师(并且您的应用程序是中等到小),请选择第一种方法,否则选择第二种方法。
顺便说一句,你会发现.NET应用程序使用第一种方法,而Java应用程序则使用第二种方法。