通过ADO提供的存储过程调用方法和直接使用sql语句又什么差别

[勾留WY]

String sql="exec SP_hdasuhda"; 然后执行
和
SqlCommand myCommand = new System.Data.SqlClient.SqlCommand("P_Test",myConnection);
myCommand.CommandType=CommandType.StoredProcedure;
有什么区别

[全栈极简]

区别就是exec SP_hdasuhda是执行的sql语句，需要通过网络传到数据库后，再编译一下。而后者不需要编译，直接执行。因此后者效率更高。

[勾留WY]

引用 3 楼 guwei4037 的回复:

区别就是exec SP_hdasuhda是执行的sql语句，需要通过网络传到数据库后，再编译一下。而后者不需要编译，直接执行。因此后者效率更高。

哦，原来是这样，谢谢您了

[by_封爱]

如果你的存储过程 只是执行一个insert 的话. 这样是没区别的. 但是如果你的存储过程有output呢?这样的话 你执行sql是没办法接收值的..

[勾留WY]

引用 1 楼 diaodiaop 的回复:

如果你的存储过程 只是执行一个insert 的话. 这样是没区别的. 但是如果你的存储过程有output呢?这样的话 你执行sql是没办法接收值的..

您的意思是，如果不返回一个值，就没什么区别，是吧？

[秋的红果实]

再补充点，方便查询优化、管理，方便复用，因为存储过程是放在一起的

[秋的红果实]

其实，现代软件系统，对存储过程还是有很多争议的，该不该将某些功能交给数据库去完成，交给多少，耦合度等等问题

[以专业开发人员为伍]

至少对于 SQL Server来说，所有的语句都是会编译的。比如说你写一个查询语句，特别是参数查询语句，那么 SQL Server就会把编译结果缓存起来。下次遇到词法模式相同的查询语句，就会自动取出编译缓存结果。 在一个大系统开发过程中，其实注重开发效率具有非常高的价值。程序要改变和重构几千遍，你不可能管理几千个存储过程，那么你随时修改 sql 语句则是即能保证运行效率又能获得极高开发效率的做法。而存储过程其实是用来打包、迁移一些非常复杂的东西，这个时候能体现出其“效率”，绝不是为了方便开发而用。

[以专业开发人员为伍]

比如说你写

select 1 from table1 where id='1234'

那么 sql server 就会在下一次执行

select 1 from table1 where id='283848kakkas'

的时候自动使用编译结果，会自动参数化查询。 sql 语句基本语法比较规范，而存储过程语法则千差万别。当我们考虑到程序员可能将来需要针对不同的数据库系统进行开发时，我们就逐步地要求程序员把数据库就当作纯数据存储和索引的载体，而不是当作业务过程的载体，业务代码写在应用中而不是用存储过程。特别是当开发复杂一点的项目时要不断地编写查询，直接写 sql 查询的开发效率很高。 至于说执行效率，我觉得你尽可以自己写测试程序来打印一下查询时间，看看有没有明显差别。这是很简单的测试。

[xuzuning]

#3 正好说反了

[以专业开发人员为伍]

引用 2 楼 qq_36235464 的回复:

[quote=引用 1 楼 diaodiaop 的回复:] 如果你的存储过程 只是执行一个insert 的话. 这样是没区别的. 但是如果你的存储过程有output呢?这样的话 你执行sql是没办法接收值的..

您的意思是，如果不返回一个值，就没什么区别，是吧？[/quote] 还是以 SQL Server 数据库系统为例，存储过程不仅仅可以用 t-sql 语言来写，也可以用 c# 代码来写，可以调用 .net 类库。可以说这是一个很“重”的解决方案，自然有其“重的”一些应用。 不过假设要求我们举重若轻，能够把极大极高并发要求的分布式系统设计得架构优雅，那么我们就会去掉满脑子只有一些数据库系统存储过程的那种30年前的想法，而把精力放到分布式、异步处理服务器系统设计上来。