存储过程适用于你吗？
用存储过程有如下几个突出优点：
" 提高新能，减少了网络流量
" 在数据库端一点的维护（single point of maintenance ）
" 抽象和概化业务逻辑，增强了一致性和安全性
" 减少了一些可能的恶意攻击的机会
" 鼓励执行计划的重用性（Encourage execution plan re-use ）
如果你的应用程序能有效的利用存储过程的上述优点，那么你就应该尽量使用。但是如果你的应用要求有很高的可移植性，或者数据库的结构变动很大，不能相对稳定下来，那么你可能要试一试其他方法了。比如你现在在SQL数据库上为用户开发一个早期可行性验证程序，今后用户很可能使用MySQL或是Oracle等其它数据库，那么你就因该避免使用SQL数据库的存储过程，而使用程序内嵌的数据库操作语句。这样当你更换数据库平台的时候，可以极大的保证程序不受影响。
另外，你还要考虑使用存储过程的技术问题。也许你和你的手下非常不熟悉存储过程编程，并且没有时间去很快掌握它。这些因素你也需要通盘考虑。另外如前所述，数据库存储过程擅长于基于集合（set-based）的操作，而不擅长基于行（row-based）的操作。如果你对存储过程没有很好的了解，而不正确的使用了它往往会导致很不好的执行性能。所以如果你决定使用存储过程，那么多花一些时间来学习它是很有必要的。使用 SET NOCOUNT ON
在缺省情况下，存储过程返回被该存储过程影响的表的行数（Rows），然而在大多情况下，这一信息是不重要的，大多数程序也不使用这一信息。使用SET NOCOUNT ON语句将停止这一行为。这将减少一次或多次客户端和数据库间的往返（具体数量取决于这一存储过程包含有多少语句影响行数（affect rows））。通常来说，这是一个小的开销，问题不大。但是对于流量很大的应用却可能会造成比较大的影响，所以建议使用SET NOCOUNT ON。具体语法如下所示：
|
不要使用 sp_ 前缀（sp_prefix）
sp_前缀是SQL数据库的保留字，是专用于系统存储过程的。数据库的引擎会首先在主控数据库（Master Database）中寻找有这个前缀的存储过程。也就是说在搜寻完主控数据库后，如果没有发现该名称的存储过程才会搜寻用户具体适用的数据库，这显然增加了搜索的时间。如果主控数据库中有和你定义的存储过程同名的存储过程，那么主控数据库的那个将会被执行，而你的则会被忽略。
保守的使用条件参数（Optional Parameters）
在使用条件参数的时候一定要考虑清楚。如果使用不当则很可能会严重的影响性能。如果执行不是根据传入的参数的组合的话，你就不必要使用它。你可以在存储过程中使用条件语句（conditional coding）来达到类似的效果。当然要列举所有可能的参数组合并一一给出对应的执行语句段是比较繁复和比较容易出错的。使用时一定要小心。
尽量使用输出（OUTPUT）参数
如果你的存储过程只返回标量值（scalar data），那么使用输出参数会提高执行的效能。原因是使用使用输出参数避免了生成一个Result set对象，从而减少了开销，提高了速度。（另外你还可以使用输出参数来返回一个cursor。在什么情况下使用这个方案更有效是一个比较复杂的问题，留待以后有机会再具体讨论）
提供返回值（RETURN Value）使用返回值来回传存储过程的执行结果是一个比较好的做法。如果在你所在的开发小组中大家能事先商定一套返回值来代表不同的执行结果，那么将会极大的便利各种错误处理，并可能给前台用户显示一些更有意义的错误信息。
先使用DDL, 然后再使用DML
如果数据库定义语句（data definition language，DDL）在数据库操作语句（data manipulation language, DML）之前，那么数据库将重新编译存储过程。这样保证DML使用的是DDL刚刚修改过的对象。所以说如果你将DDL语句统统放在DML语句之前，那么数据库只要重新编译一次存储过程。如果你将DDL和DML语句混杂在一起，那么数据库会多次编译存储过程，这样就降低了系统的效率。
使用注释（Comments）你应该注释你的T-SQL程序。这样将来不管是谁负责这些程序，他们都会更好的理解这些程序的意义和目的。写注释是一个程序员因该具备的最起码的素质。