ストアドプロシージャの定義
ストアド プロシージャは、実際には、実行可能なプロシージャにプリコンパイルされた 1 つ以上の SQL ステートメントです。ストアド プロシージャの機能は、パラメータを呼び出して渡すことによって完了できます。
CREATE PROC | PROCEDURE プロシージャ名
[{@parameter_datatype} [=default_value] [OUTPUT],
{@parameter_datatype} [=default_value] [OUTPUT],
....
]
AS
sql_statements
GO
ストアド プロシージャは、パラメータありまたはパラメータなしで作成できます。パラメータなしのストアド プロシージャは、通常、パラメータを渡す必要のないステートメントを実行することで完了できる関数です。パラメータありの場合は、上の例と同様に、パラメータを渡す必要がある SQL ステートメントです。 2 つのパラメータが SQL ステートメントに渡されます。パラメータを持つものについてはパラメータのタイプを定義する必要があり、文字タイプについては長さを定義する必要があり、パラメータへのデフォルト値の追加はオプションです。
ストアド プロシージャの利点
性能を上げる
SQL ステートメントは、プロシージャの作成時に分析およびコンパイルされます。ストアド プロシージャはプリコンパイルされています。ストアド プロシージャが初めて実行されるとき、クエリ オプティマイザはそれを分析して最適化し、最終的にシステム テーブルに保存されるストレージ プランを提供します。これにより、プロシージャの実行時にこのオーバーヘッドが節約されます。 。
ネットワークのオーバーヘッドを削減する
ストアド プロシージャを呼び出すときは、ストアド プロシージャ名と必要なパラメータ情報のみを指定する必要があるため、ネットワークのトラフィックが軽減されます。
コードの移植が容易
データベースの専門家はいつでもストアド プロシージャを変更できますが、アプリケーション プログラムのソース コードには影響を与えないため、プログラムの移植性が大幅に向上します。
より強力なセキュリティ
システム管理者は、特定のストアド プロシージャの権限を制限して、権限のないユーザーがデータにアクセスできないようにすることができます。ネットワーク経由でプロシージャを呼び出すと、実行されたプロシージャの呼び出しのみが表示されます。したがって、悪意のあるユーザーはテーブルやデータベースのオブジェクト名を確認したり、独自の Transact-SQL ステートメントを埋め込んだり、重要なデータを検索したりすることができません。
プロシージャ パラメータを使用すると、SQL インジェクション攻撃を回避できます。パラメーター入力は実行可能コードではなくリテラル値として扱われるため、攻撃者がプロシージャ内の Transact-SQL ステートメントにコマンドを挿入してセキュリティを侵害することがより困難になります。
プロセスを暗号化できるため、ソース コードの難読化に役立ちます。
ストアド プロシージャの欠点
ロジック処理が難しい
SQL 自体は構造化クエリ言語ですが、オブジェクト指向ではなく、本質的には手続き型言語であるため、複雑なビジネス ロジックに直面すると、手続き型の処理は非常に困難になります。同時に、SQL はビジネス ロジックの処理よりもデータ クエリに優れているため、すべてのビジネス ロジックをストアド プロシージャに含めると、この原則に違反します。
パラメータの変更は複雑です
ストアド プロシージャに入力されたパラメーターを変更する必要がある場合、またはストアド プロシージャから返されるデータを変更する必要がある場合でも、アセンブリ内のコードを更新してパラメーターを追加したり、呼び出しを更新したりする必要があります。この時点で面倒。
開発とデバッグが複雑になる
IDE の問題のため、ストアド プロシージャの開発とデバッグは一般的なプロシージャよりも困難です。
キャッシュを適用できません
キャッシュにはグローバル一時テーブルなどの方法もありますが、データベースへの負担も大きくなります。キャッシュの同時実行性が高く、ロックが頻繁に必要になる場合、効率が非常に心配になります。
クラスタはサポートされていません
データベース サーバーを水平方向に拡張したり、データベースを (水平方向または垂直方向に) 切断したりすることはできません。データベースが切断された後、ストアド プロシージャはデータがどのデータベースに保存されているかを認識できません。
ストアド プロシージャは、ビジネス ボリュームが小さいシステムで広く使用されており、すべてのロジックは処理のためにデータベースに渡され、一部のロジック関数は迅速に完了できます。ただし、業務量が比較的大きいシステムでは、データベースへの負担が大きすぎるため、ストアド プロシージャの使用は通常禁止されています。