SQL Serverストアドプロシージャ

ストアドプロシージャは、高効率とセキュリティの利点を提供します。

Microsoft SQL Serverには、Transact-SQLステートメントを管理可能なブロックにグループ化することで、データベース開発プロセスを簡素化するストアドプロシージャメカニズムが用意されています。 ストアドプロシージャは、大部分のSQL Server開発者が享受している効率とセキュリティのメリットが、時間の先行投資の価値があることがわかっています。

ストアドプロシージャを使用する利点

開発者がストアドプロシージャを使用する理由

この技術の主な利点は次のとおりです。

• プリコンパイルされた実行： SQL Serverは各ストアドプロシージャを一度コンパイルしてから、実行計画を再利用します。 ストアドプロシージャが繰り返し呼び出されると、パフォーマンスが大幅に向上します。
• クライアント/サーバートラフィックの削減：ネットワーク帯域幅が環境に影響する場合は、ストアドプロシージャが長いSQLクエリを1つの回線に送信することができます。
• コードとプログラミングの抽象化の効率的な再利用：ストアドプロシージャは、複数のユーザーとクライアントプログラムで使用できます。 計画的にそれらを活用すると、開発サイクルの短縮に時間がかかります。
• 強化されたセキュリティー制御：ユーザーに、基礎となる表の権限とは独立してストアード・プロシージャーを実行する権限をユーザーに与えることができます。

ストアドプロシージャはユーザー定義関数と似ていますが、微妙な違いがあります。

構造

ストアドプロシージャは、他のプログラミング言語で見られる構造体に似ています。

実行時に指定された入力パラメータの形式でデータを受け取ります。 これらの入力パラメータ（実装されている場合）は、何らかの結果を生じる一連のステートメントの実行に使用されます。 この結果は、レコードセット、出力パラメータ、およびリターンコードを使用して呼び出し環境に戻されます。

一口のように聞こえるかもしれませんが、実際にはストアドプロシージャは非常に簡単です。

例

このページの下部に表示される目録という名前のテーブルに関連する実用的な例を見てみましょう。 この情報はリアルタイムで更新され、倉庫管理者は倉庫に保管されて出荷可能な製品のレベルを常にチェックしています。 以前は、各マネージャは次のようなクエリを実行していました。

SELECT製品、数量
FROM在庫
WHERE倉庫= 'FL'

その結果、SQL Serverでのパフォーマンスが非効率的になりました。 倉庫管理者がクエリを実行するたびに、データベースサーバーはクエリを再コンパイルして最初から実行しなければなりませんでした。 また、倉庫管理者は、テーブル情報にアクセスするためのSQLと適切な権限について知っておく必要がありました。

代わりに、ストアドプロシージャの使用によってプロセスを簡素化できます。 特定の倉庫の在庫レベルを取得するsp_GetInventoryというプロシージャのコードを次に示します。

CREATE PROCEDURE sp_GetInventory
@location varchar（10）
として
SELECT製品、数量
FROM在庫
WHERE倉庫= @場所

フロリダの倉庫管理者は、次のコマンドを発行して在庫レベルにアクセスできます。

EXECUTE sp_GetInventory 'FL'

ニューヨークの倉庫管理者は、同じストアドプロシージャを使用してその地域の在庫にアクセスできます。

EXECUTE sp_GetInventory 'NY'

確かに、これは簡単な例ですが、ここで抽象化の利点を見ることができます。 ウェアハウス・マネージャーは、SQLまたはプロシージャーの内部動作を理解する必要はありません。 パフォーマンスの観点から、ストアドプロシージャは不思議に作用します。 SQL Serverは実行計画を一度作成し、実行時に適切なパラメータをプラグインして再利用します。

ストアドプロシージャの利点を学んだので、ここに出てそれらを使用するようになりました。

いくつかの例を試して、達成されたパフォーマンスの向上を測定してみてください。あなたは驚くでしょう！

在庫表