2011-02-03 6 views
16

2つのストアドプロシージャがあり、そのうちの1つは支払いリストを返し、もう1つは通貨でグループ化された支払いの概要を返します。今すぐ、私は重複したクエリを持っています:支払いの一覧を返すストアドプロシージャのメインクエリは、通貨で支払いの要約を返すストアドプロシージャのサブクエリです。私は、支払いの一覧を通貨で支払の概要を返すストアドプロシージャのサブクエリを返すストアドプロシージャを作成することによって、この二重性を排除したいと思います。それはSQL Server 2008で可能ですか?SQL Server 2008でサブクエリとしてストアドプロシージャを使用することはできますか?

答えて

15

最初のprocをTABLE-VALUED関数に変換したほうがよいです。複数のステートメントが関係する場合は、最初にリターンテーブル構造を定義し、それを移入する必要があります。

サンプル:

CREATE proc getRecords @t char(1) 
as 
set nocouut on; 
-- other statements -- 
-- final select 
select * from master..spt_values where type = @t 
GO 

が - になり -

CREATE FUNCTION fn_getRecords(@t char(1)) 
returns @output table(
    name sysname, 
    number int, 
    type char(1), 
    low int, 
    high int, 
    status int) as 
begin 
-- other statements -- 
-- final select 
insert @output 
select * from master..spt_values where type = @t 
return 
end; 

をしかし、それはストレートの選択である(または単一の文として書くことができる)場合は、INLINEを使用することができます高度に最適化されたtvf形式

CREATE FUNCTION fn2_getRecords(@t char(1)) 
returns table as return 
-- **NO** other statements; single statement table -- 
select * from master..spt_values where type = @t 

2番目のprocは、最初のprocから単に選択します

create proc getRecordsByStatus @t char(1) 
as 
select status, COUNT(*) CountRows from dbo.fn2_getRecords(@t) 
group by status 

そして、あなたは結果を得るために

EXEC firstProc @param 

を呼び出すために使用される場合は、あなたは今、それをパラメータ化する必要がない限り、私は、ビューを使用することになり、それから

SELECT * FROM firstProc(@param) 
+0

ストアドプロシージャがCUBEでOPENQUERYを実行する必要がある場合はどうなりますか?関数内ではそのことはできません。 –

6

ストアドプロシージャの出力をテンポラリテーブルにキャプチャし、メインクエリでテーブルを使用することができます。

列IDおよびNameを表変数に戻すストアド・プロシージャの出力を取得します。あなたは、テーブル値関数にリストを返す手続きを行った場合

declare @T table (ID int, Name nvarchar(50)) 

insert into @T 
exec StoredProcedure 
+0

すみません...あなたはtemp *** FILE ***と言っていますか?それは技術的に実現可能な解決策ですが、巨大な一時ファイルを常に作成して削除する余裕はないと思います。 – pyon

+0

Tempテーブルでは、それは答えで修正されましたが、上記のコメントが古くなって混乱するかもしれない将来の読者を明確にしたかっただけです。 – Remi

3

、その後、私はあなたがサブクエリでそれを使用することができます信じています。

6

ストアドプロシージャの結果をテーブル変数または一時テーブルに挿入すると、そのトリックが実行されます。

SQL Serverのコードをあるクエリから次のクエリに再利用しようとすると、テーブル機能の柔軟性が向上します。パラメータを渡す必要がない場合や、あらゆる種類のフロー制御ロジックを使用する必要がない場合は、ビューは問題ありません。これらは、他の関数、プロシージャ、ビュー、またはt-SQL文のテーブルと同様に使用できます。

+0

私はジェフに同意します。テーブル値関数は、このようなことに最適です。 – brian

1

を選択し、テーブル値の関数を使用できるマルチステートメント操作でなければならない限り、可能な場合はインラインのテーブル値関数を使用しますが、通常は効率が悪いです。

+0

両方のクエリを実行するためにパラメータを取る必要があります。これがストアドプロシージャを使用している理由です。 – pyon

+0

@Eduardo Leon可能であれば、私はインラインのテーブル値関数を使用します。これらは、オプティマイザがどのようにそれらを処理し、それらを基になるビューやITVFを呼び出すコードと組み合わせるかという点で、パラメータ化されたビューと実際は同じです。 –

+0

クエリの 'FROM'節でITVFを呼び出せますか? – pyon

関連する問題