讨论！何时应该采用存储过程，何时不宜采用存储过程？

[chequan]

高手通常反对全部采用存储过程，也同时反对全部不采用存储过程。
请问哪些情况适于采用存储过程，哪些情况适于直接在ASP.NET中写SQL语句？请指点，谢谢！

[chequan]

继续讨论！

[以专业开发人员为伍]

有的人仅仅为了参数查询，就把单条查询语句封装到一个个存储过程中，这大可不必。特别是在开发当中新的查询语句经常装造出来。那种把每一个查询都封装成存储过程的，不到没有提高复用水平，而且自己都懒得再去记或者保持存储过程的含义，新查询还是又创建新的存储过程，造成数据库里边一大堆命名和功能莫名其妙的存储过程，维护也不行、删除也不行。

如果为何防SQL注入，大可不必使用存储过程，只要是获得的非文本变量都要写入强类型的变量中然后再形成SQL，对于文本组合进SQL的文本中常量中要使用.Replace("'","''")就行了。

[Mirricle]

存储过程不光是为了防止注入吧
是为了预编译

[以专业开发人员为伍]

用存储过程封装单个查询，并不会提高查询速度。 SQL Server会对类似的(可以自动替换简单常量的)SQL查询自动使用上一次的编译结果，这与明确地写参数查询语句（executeSQL @a,@b,@c形式的）类似。把查询再封装尽存储过程不但没有减少这种查询分析优化的时间，反而更慢。

[Mirricle]

还为了分层 哈哈

[chequan]

我并不担心移植，因为根本就不考虑移植。所以排除移植这一点。

[chequan]

CREATE PROCEDURE [GetSettings]
(
@GroupName varchar(50) = NULL
)
WITH ENCRYPTION
AS
SELECT
S.*
FROM
tbl_Setting S
WHERE
(@GroupName IS NOT NULL AND S.GroupName = @GroupName) OR @GroupName IS NULL

RETURN
GO
比如这样一个简单的存储过程。用SQL也很容易写。
因此对于这种用存储过程和用SQL都很容易写的情况下，用哪种好呢？

[kkeemmgg]

无论什么时候都应该使用存储过程.有人说这不便于移植,想问下,有多少你写的程序移植过了.

[以专业开发人员为伍]

一定写成应用程序里边的查询，这样维护也很方便，因为他在业务对象那里。如果数据库里边有三四百条命名和参数莫名其妙的存储过程，其中只有一条查询语句，程序里边只是引用存储过程，读这样的程序和维护的时候非常容易让人冒火，并且在尝试稍微修改的时候你不敢去修改存储过程（因为也许会让其它不可预知的地方出错），而只敢重新按照他的制造垃圾的习惯再变本加厉地制造一个。

我上面已经说过，即使查询放在循环里边，SQL Server也不会在每一次执行的时候都对查询语句从头分析，而会复用上一次的分析结果。其实即使慢一些，我也宁愿写成灵活的查询。

你说的这个查询这样写(假设@GroupName从控件myGroup中来)：

dim SQL as string="SELECT S.* FROM tbl_Setting S WHERE '{0}'='' OR S.GroupName ='{0}'"
SQL=string.format(SQL,myGroup.text.replace("'","''"))
'然后通过 sqlCommand 获得输出。

[以专业开发人员为伍]

实际上，存储过程用于封装较复杂或者复用性很高的过程，例如好几个复杂的数据更新动作包含在Transaction中，这个过程可以肯定对程序员有很深刻的含义、很清晰的记忆、很充分地复用，改进它一个地方就可以改进整个系统某一具体业务处理的整体运行效率或者流程处理方式。

[chequan]

谢谢！

[luojinat2005]

存储过程可以减少服务器和数据库之间的流量,
存储过程是经过预编译和优化的,
-------------------------------------------
一般情况下简单,简短的查询语句可以直接查询,
比较复杂,比较长的查询语句,以及一些列的数据库批处理过程最好用存储过程.如事务应用等
存储过程还有一大好处就是重复利用,还可以使数据库编程整体思路清晰
-------------------------------------------------
存储过程对于分层开发,团队合作,以及后期修改维护都有很大的好处

[luojinat2005]

存储过程是对一系列普通查询语句的封装,
要写出高效率,高性能,以及高复用性的存储过程,
要以高效率,高性能,以及高复用性的一系列普通查询语句为基础,
就像盖房子一样,材料不行的话,盖出来的房子应该不怎么样.

[luojinat2005]

推荐两本书给你:
基础:SQL Server 2000 Transact-SQL程序设计
作者：章立民
出版社：中国铁道出版社
提升:Transact-SQL权威指南
作者：[美]Ken Henderson
出版社：中国电力出版社

[以专业开发人员为伍]

哦，从正统的文法角度讲，封装查询（包括复杂一点的查询）为存储过程是“坏味道”的写法。“坏味道”这个词是从设计模式中学来的。

常用的查询，请使用视图和用户定义函数，使用存储过程是至少几年前就淘汰的方法了。过去因为没有用户定义函数，而视图不接受参数，才用这种不论不类的文法。

在编译性等任何一个方面存储过程都不比视图和UDF优越，而表现力上又极差。

使用UDF的一个例子，例如查询“所有3月到7月出生的拥有驾照的人中年龄最大的20个人”，可写：

select top 20 * from dbo.查询有驾照的人(3,7) order by 年龄

[永远-]

为了分层，全用存储过程，便于管理！数据库里的命名也得规范！！！总之，我现在是全用

[自然框架]

我是一半一半

添加、修改、删除 用存储过程。目的是写操作日志方便一点，再有就是事务处理。

查询用查询语句，只是由我的翻页控件来定了。速度也是很快的。

其他的看情况了


现在遇到的最大的问题是：

数据服务器是放在客户的局域网里的，我是绝对没有办法连到客户的数据服务器的。

交付用户使用以后，如果要修改某个存储过程，那怎么办？

链接客户的数据服务器就不用想了；已经填入数据了，发个数据库的备份也是不行的。

我把存储过程写好后传给客户的管理员，让他来修改？如果他不会怎么办？这是很不方便和安全的。

写一个“升级程序”，让管理员运行一下？也不是很方便。

恐怕就是有跑过去一趟了。如果客户在外地呢？？？


如果是写在程序里的话，那就方便了，传一个DLL过去，让客户的管理员覆盖一下文件就可以了。

[以专业开发人员为伍]

如果程序可以连上数据库服务器，就能使用 DDL 命令更新任何对象。

[以专业开发人员为伍]

分层跟具体什么 SQL 形式没有什么关系了。如果为了将数据库的特性隐藏起来，只提供对象化的业务层，这种分层还有它的不容忽视的作用，那么SQL的隐藏方式完全一样，不论是查询语句还是存储过程都是同样地对待。如果说数据库内部要T-SQL语句写法“分层”，分出哪种表现形式比其他的高级，这完全是人为的随意的。

[自然框架]

我好像说过了，绝对连不到客户的数据服务器的。