两个存储过程的比较

[zhengmushang]

请问以下两种存储过程的写法各有什么优势？
一般看到的都是第一种写法，第二种很少人用，但感觉第二种更简单啊？？？


第一种：

CREATE PROCEDURE pro1
declare @sql varchar(300)
set @sql = 'select * from table1 where id <10'
exec(@sql)
GO

第二种：

CREATE PROCEDURE pro1
select * from table1 where id <10
GO

[zccmy22]

如果是你现在的这两个的确一样。

但是如果有入参就不一样了。

[igelf]

mark

[wbandzq]

看你传不传参数

[zzxap]

第二个根本不算存储过程，都没有执行sql，也没有定义

[zzxap]

语法都不对

[liuhong_0325]

这样的有必要写存储过程吗？？ 下面那个简直是招打啦。。 老板都会给他气晕过去的！！


存储过程用于要传参比较复杂的语句啦。 还要有判断啦。 有你想要的输入输出值啦！！

[moonshineidolon]

CREATE PROCEDURE pro1
declare @sql varchar(300)
set @sql = 'select * from table1 where id <10'
exec(@sql)
GO

这种写法 常用，但是没有利用到存储过程的预编译功能。效率不高，但是灵活。

第二种：
SQL code

CREATE PROCEDURE pro1
select * from table1 where id <10
GO

这个写法执行效率高

[zccmy22]

CREATE PROCEDURE pro1
@Effect datetime,
@Expiry datetime，
@IsNeedTime varchar(1)
declare @sql varchar(300)
set @sql = 'select * from table1 where id <10 '
if @IsNeedTime = 'T'
begin
set @sql = @sql + 'and time between ''' + @Effect + ''' and ''' + @Expiry + ''''
end

exec(@sql) GO

这是两个入参，且比较简单。如果你传入的入参是一个字符串。‘001,002,003,004'
你是不是先需要拆分这个数据，如果特殊需要再做循环怎么办。

如果入参更多，通常，几十个入参的都有。请问你怎么处理，难不成，用每个方法。就一直往后写吗？请问那样的代码神先能看懂啊？。呵呵。具体例子不想举了。因为太烦了，总之。因需页异，你这个是查询，如果是update，insert怎么办呢。有可能还有好多判断，

[zccmy22]

CREATE PROCEDURE pro1
@Effect  datetime,   
@Expiry  datetime，
@IsNeedTime varchar(1)   
declare @sql varchar(300)
set @sql = 'select * from table1 where id <10 '
if @IsNeedTime = 'T'
begin
set @sql = @sql + 'and time between ''' +  @Effect + ''' and ''' + @Expiry + ''''
end
 
exec(@sql) GO 

[zccmy22]

如果如最后一种那样，请问。你直接写sql是不是利用率太低了呢？

if @IsNeedTime = 'T'
begin
 select * from table1 where id <10  and time between + '''' +  @Effect + ''' and  ''' + @Expiry + ''''
end
else
begin
 select * from table1 where id <10 
   
end 

可能写的有点问题吧，大体就是这意思，如果就两个情况还好。要是有五种十种呢？如何判断 。

[zccmy22]

if @IsNeedTime = 'T'
begin
 select * from table1 where id <10  and time between   @Effect  and   @Expiry 
end
else
begin
 select * from table1 where id <10 
   
end 

呵呵，报歉,写错了，更正一下。呵，有点晕了。

[ffyyn]

mark..