【分页】用不用存储过程的区别

[天罡gg]

【分页】方案网上有很多，对于好多项目来说都有它存在的意义。
网上流行很多分页存储过程，可以说都是前人研究的成果，值得学习和借鉴。

以前做的项目也是用的分页存储过程，当时从网上找来，觉得好高深的SQL啊，那么长看不懂，觉得大家都这么用肯定没错。
后来看到了分页存储过程也可以SQL注入，所以细心的看了下分页存储过程中的代码，发现

这不就是在存储过程里面拼接sql，然后EXEC！！
那我就不明白了，这和在程序里面拼接sql不是一样的吗？？？
在程序里再复杂我都可以简单看懂，为什么要到存储过程里面拼接sql？？

在本机分别测试了一下用/不用存储过程对千万级别的表的分页速度，差不多啊！！
难道还有客户端与服务器端的差别？我现在没法在服务器上测试，所以只有在这求解答了。
真的不明了，高手给点提示吧！！

[threenewbee]

你看的是哪里找来的存储过程。

拼凑SQL和注入没有必然的联系。如果拼凑的内容并非来自用户输入，是不会有问题的。

[jeje]

关注.....

[天罡gg]

[Quote=引用 1 楼 caozhy 的回复:]

你看的是哪里找来的存储过程。

拼凑SQL和注入没有必然的联系。如果拼凑的内容并非来自用户输入，是不会有问题的。
[/Quote]

现在所有的分页存储过程模式都是一样的，在存储过程中拼SQL，然后EXEC，这个不可否认吧？
如果不对查询条件做特殊字符过滤，就有可能SQL注入。
参见原文：http://www.cnblogs.com/yukaizhao/archive/2007/03/09/pagination_proc_problem.html

[天罡gg]

[Quote=引用 3 楼 wuzhanhui 的回复:]

因为存储过程是预编译的，所以执行的效率比较高，所以一般都把sql语句并接在存储过程里面了
[/Quote]

分页存储过程和普通存储过程不一样的，因为他里面是用EXEC(拼接的SQL)形式。
那我在程序里拼SQL，
SqlCommand cmd = new SqlCommand(拼的SQ);
和
SqlCommand cmd = new SqlCommand("ExecSql");
cmd.Parameters.Add(拼的SQ);
有什么不同？到底谁更高效？

Create proc ExecSql
( @sql varchar(4000))
as
BEGIN
 Exec @sql
END

[ljjk123]

差距不大，而且，如果这个使用存储过程，因为过于频繁，还有其他风险。
毕竟sql可以想断就断，存储过程执行到一半，你不用了，它就不是想断就断的了
事务无法关闭之类的错误，还会危害数据库

[鸭梨山大帝]

"
这不就是在存储过程里面拼接sql，然后EXEC！！
那我就不明白了，这和在程序里面拼接sql不是一样的吗？？？
在程序里再复杂我都可以简单看懂，为什么要到存储过程里面拼接sql？？
"

"那我就不明白了，这和在程序里面拼接sql不是一样的吗？？？"
功能上是一样的,没有任何差别.
性能上也差别不大,如果是exec不是sp_execsql的话,也不存在预编译,每次都是重新编译的.
但是从隔离,封装的角度看,意义就大一些了,至少把做同一件事情的TSQL封装在一起了,更直观,更易于维护

"在程序里再复杂我都可以简单看懂，为什么要到存储过程里面拼接sql？？"
在.NET程式里面,在存储过程里面,都是一样的T-SQL,为何看得懂一边,看不懂另外一边?

另外分页不一定要直接用T-SQL/SP来实现,也可以用Linq(当然实质上其也是把Linq转换为T-SQL语句提交给数据库服务器的,只是我们不再关注这种转换)

[鸭梨山大帝]

"
SqlCommand cmd = new SqlCommand(拼的SQ);
和
SqlCommand cmd = new SqlCommand("ExecSql");
cmd.Parameters.Add(拼的SQ);
有什么不同？到底谁更高效？
"

这里考量的不是高效不高效,从执行效率来说,如果参数不是频繁变化 SqlCommand cmd = new SqlCommand("ExecSql"); 要高些,但是如果Exec @sql中@sql是随时变化的,那么效率没啥差别.

这里考量的是封装,安全性,可读性
用cmd.Parameters.Add的方式可以防止注入
而且调用与输入是分离的,一目了然.

[monkeyHere]

我的理解是存储过程相当于一个类~虽然程序代码本身也可以实现，但是类提供了管理的方便~

[挨踢直男]

在本机分别测试了一下用/不用存储过程对千万级别的表的分页速度，差不多啊！！

--------------------

怎么可能，你存储过程写的有问题

[挨踢直男]

如果你把程序中的sql逻辑一模一样的放到存储过程中，那肯定没差别的，可以忽略不记

程序过程的优点就是可以数据操纵逻辑封装在一起

[天罡gg]

[Quote=引用 11 楼 aspwebchh 的回复:]

如果你把程序中的sql逻辑一模一样的放到存储过程中，那肯定没差别的，可以忽略不记

程序过程的优点就是可以数据操纵逻辑封装在一起
[/Quote]

这么说我就放心了

[天罡gg]

[Quote=引用 7 楼 lost_painting 的回复:]

"
这不就是在存储过程里面拼接sql，然后EXEC！！
那我就不明白了，这和在程序里面拼接sql不是一样的吗？？？
在程序里再复杂我都可以简单看懂，为什么要到存储过程里面拼接sql？？
"

"那我就不明白了，这和在程序里面拼接sql不是一样的吗？？？"
功能上是一样的,没有任何差别.
性能上也差别不大,如果是exec不是sp_execsql的话,也不存在预编译,每次都是重新编译……
[/Quote]

你这个回答我最满意了，呵呵，明白了