ストアドプロシージャとテーブル値関数を使用するのが適切な場合

Question

現在、ほとんどのレポートではストアドプロシージャを使用していますが、結果セットをさらに条件付きで結合できる柔軟性がありたいと思います。保存されprocsのでこれを行うには

、私は下図のように一時テーブル内にStoredProcから結果セットを保存する必要があります。

CREATE TABLE #Top_1000_Customers (
    CustomerCode BIGINT, 
    Firstname VARCHAR(100), 
    Surname VARCHAR(100), 
    State VARCHAR(), 
    MonthlySpend FLOAT) 

INSERT INTO #Top_1000_Customers 
EXEC FindTop1000Customers() 

SELECT CustomerCode, Firstname, Surname, State, MonthlySpend float 
FROM #Top_1000_Customers 
WHERE State = 'VIC' 

DROP TABLE #Top_1000_Customers 

私は、テーブル値関数を使用してこれを行う場合は、このコードは次のようになります。

SELECT FindTop1000Customers() 
WHERE State='VIC' 

私が望むのは、テーブル値関数を別のテーブルと結合することもできます。

これは、格納されたprocsを使用するよりも少し上品であると思われます。また、パフォーマンスが向上するように見えます。結果を一時表にスプールする必要がないためです。

テーブル値関数を使用する代わりに、ストアドプロシージャを使用してこれらのタイプのタスクを実行する方が良い理由はありますか？

Answer 1

FindTop1000Customersプロシージャを単一のSELECT文で表現できますか？そうであれば、インラインのテーブル値関数が良い代用品になるかもしれません。 State = 'VIC'基準は基本テーブルにプッシュダウンされ、クエリは非常に高速に実行されます。

そうでない場合、WHERE句を適用する前に、複数のステートメントを持つテーブル値関数は、完全な結果セットを実現する必要があります。フィルタをベーステーブルにプッシュするには、ストアドプロシージャと同じように、関数をパラメータ化する必要があります。そして、プログラミングの力（一時テーブル、動的SQLなど）を失うことになります。

私はErland Sommarskogの記事をHow to Share Data Between Stored Procedures、Dynamic Search Conditions、およびDynamic SQLで提案します。

Answer 2

ストアドプロシージャには適用されない一般的な関数には制限があります。 User-Defined Function Design Guidelinesを参照してください。

Answer 3

インラインテーブル値関数は、パラメータ化されたビューと同等です。オプティマイザはビューのようにインライン展開できるため、データベースロジックを強制する方法としては非常に適しています。インラインTVFは明らかにすべてのロジックをインラインにしなければならないので、できることには限界があります。

複数行のテーブル値関数は、一方で柔軟性がありますが、ストアドプロシージャと比較してその機能は慎重に検討する必要があります。

あなたの場合は、通常のビューまたはインラインTVFで行うことができる場合は、まずそれを行います。