详谈存储过程

hery2002
苦*行*僧
等级:

发表于：2008-05-11 22:14:556楼得分:10

关于存储过程的优点
http://www.ebookit.cn/767.html
存储过程是由一些SQL语句和控制语句组成的被封装起来的过程，它驻留在数据库中，可以被客户应用程序调用，也可以从另一个过程或触发器调用。它的参数可以被传递和返回。与应用程序中的函数过程类似，存储过程可以通过名字来调用，而且它们同样有输入参数和输出参数。

　　根据返回值类型的不同，我们可以将存储过程分为三类：返回记录集的存储过程，返回数值的存储过程（也可以称为标量存储过程），以及行为存储过程。顾名思义，返回记录集的存储过程的执行结果是一个记录集，典型的例子是从数据库中检索出符合某一个或几个条件的记录；返回数值的存储过程执行完以后返回一个值，例如在数据库中执行一个有返回值的函数或命令；最后，行为存储过程仅仅是用来实现数据库的某个功能，而没有返回值，例如在数据库中的更新和删除操作。

　　使用存储过程的好处

　　相对于直接使用SQL语句，在应用程序中直接调用存储过程有以下好处：

　　(1)减少网络通信量。调用一个行数不多的存储过程与直接调用SQL语句的网络通信量可能不会有很大的差别，可是如果存储过程包含上百行SQL语句，那么其性能绝对比一条一条的调用SQL语句要高得多。

　　(2)执行速度更快。有两个原因：首先，在存储过程创建的时候，数据库已经对其进行了一次解析和优化。其次，存储过程一旦执行，在内存中就会保留一份这个存储过程，这样下次再执行同样的存储过程时，可以从内存中直接调用。

　　(3)更强的适应性：由于存储过程对数据库的访问是通过存储过程来进行的，因此数据库开发人员可以在不改动存储过程接口的情况下对数据库进行任何改动，而这些改动不会对应用程序造成影响。

　　(4) 分布式工作：应用程序和数据库的编码工作可以分别独立进行，而不会相互压制。

msdn上面相关的说明

考虑使用存储过程的理由
也许您曾经在多处编写过使用 SqlCommand 对象的 T-SQL，但却从未考虑过是否有一个比将它并入数据访问代码更好的位置。由于应用程序随着时间的推移增添了一些功能，因此其内部可能包含一些复杂的 T-SQL 过程代码。存储过程为封装此代码提供了一个替换位置。

大多数人可能对存储过程已有所了解，但对于那些不了解存储过程的人员而言，存储过程是指一组作为单个代码单元一起存储于数据库中的 T-SQL 语句。您可以使用输入参数传入运行时信息，并取回作为结果集或输出参数的数据。存储过程在首次运行时将被编译。这将产生一个执行计划 - 实际上是 Microsoft® SQL Server™ 为在存储过程中获取由 T-SQL 指定的结果而必须采取的步骤的记录。然后，执行计划在内存中得到缓存，以备以后使用。这样会改善存储过程的性能，因为 SQL Server 无需为确定如何处理代码而重新分析它，而只需引用缓存的计划即可。这个缓存的计划一直可用，直到 SQL Server 重新启动，或直到它由于使用率较低而溢出内存。

性能
缓存的执行计划曾使存储过程较之查询更有性能优势。但对于 SQL Server 的几个最新版本，执行计划已针对所有 T-SQL 批处理进行了缓存，而不管它们是否在存储过程中。因此，基于此功能的性能已不再是存储过程的卖点。任何使用静态语法，且提交频率足以阻止执行计划溢出内存的 T-SQL 批处理将会获得同样的性能好处。“静态”部分是关键；任何更改，即使像添加注释这样无关紧要的更改，也将导致无法与缓存的计划相匹配，从而将无法重复使用计划。

但是，当存储过程可以用于降低网络流量时，它们仍然能够提供性能好处。您只需在网络中发送 EXECUTE stored_proc_name 语句，而非整个 T-SQL 例程，这可以在复杂操作中广泛使用。设计良好的存储过程可以将客户端与服务器之间的许多往返过程简化为单个调用。

此外，使用存储过程使您能够增强对执行计划的重复使用，由此可以通过使用远程过程调用 (RPC) 处理服务器上的存储过程而提高性能。使用 StoredProcedure 的 SqlCommand.CommandType 时，存储过程通过 RPC 执行。RPC 封装参数和调用服务器端过程的方式使引擎能够轻松地找到匹配的执行计划，并只需插入更新的参数值。

考虑使用存储过程提高性能时，最后要考虑是否要充分利用 T-SQL 的优点。请考虑要如何处理数据。

• 是否要使用基于集合的操作，或执行 T-SQL 中完全支持的其他操作？那么存储过程就是一个选择，而内联查询也可以使用。

• 是否尝试执行基于行的操作，或复杂的字符串处理？那么可能要重新考虑在 T-SQL 中进行这种处理，这不包括使用存储过程，至少要到 Yukon 发布并且公共语言运行库 (CLR) 集成可用后，才能使用存储过程。

可维护性和抽象
要考虑的另一个潜在优势是可维护性。理想情况下，数据库架构从不更改，业务规则不被修改，但在现实环境中，情况则完全不同。既然情况如此，那么如果可以修改存储过程以包括新 X、Y 和 Z 表（为支持新的销售活动而添加了这些表）中的数据，而不是在应用程序代码中的某个位置更改此信息，则维护对您来说可能比较容易。在存储过程中更改此信息使得更新对应用程序而言具有透明性 - 您仍然返回相同的销售信息，即使存储过程的内部实现已经更改。更新存储过程通常比更改、测试以及重新部署程序集需要较少的时间和精力。

另外，通过抽象化实现并将此代码保存在存储过程中，任何需要访问数据的应用程序均可以获取一致的数据。您无需在多个位置维护相同的代码，用户便可获取一致的信息。

在存储过程中存储 T-SQL 的另一个可维护性优点是更好的版本控制。您可以对创建和修改存储过程的脚本进行版本控制，就像可以对任何其他源代码模块进行版本控制一样。通过使用 Microsoft Visual SourceSafe® 或某个其他源代码控制工具，您可以轻松地恢复到或引用旧版本的存储过程。

在使用存储过程提高可维护性时应值得注意的一点是，它们无法阻止您对架构和规则进行所有可能的更改。如果更改范围大到需要对输入存储过程的参数进行更改，或者要更改由其返回的数据，则您仍需要更新程序集中的代码以添加参数、更新 GetValue() 调用，等等。

要注意的另一个问题是，由于存储过程将应用程序绑定到 SQL Server，因此使用存储过程封装业务逻辑将限制应用程序的可移植性。如果应用程序的可移植性在您的环境中非常重要，则将业务逻辑封装在不特定于 RDBMS 的中间层中可能是一个更佳的选择。

修改删除举报引用回复