こんにちは、
この記事では、大規模なプロジェクトで使用する必要があるストアドプロシージャについて説明します。
ストアドプロシージャの違いは、大規模なパフォーマンスと効率を必要とするプロジェクトでのみ発生するため、大規模なプロジェクトでは間違いなく使用する必要があると思います。
ストアドプロシージャは、一般的に次のように記述できます。最初のコンパイル後にコンパイルする必要がなく、データベースサーバーに保持されるSQLステートメント。一方、アプリケーション層ではなくデータベースサーバーに格納されているT-SQLステートメントと言えます。
ストアドプロシージャは、他のプログラミング言語と同様に、パラメータなしで実行できます。アプリケーション開発で使用する場合はSPとも呼ばれます。すべてのデータベース操作は、ストアドプロシージャを使用して実行できます。
ストアドプロシージャを使用する最も美しい機能の1つは、プログラミング言語コードをDML（データベース操作言語）データベースクエリから分離することです。さらに、SPを作成してコンパイルすると、何度でも使用できるようになります。
一般的に、ストアドプロシージャの利点と、それらが使用されすぎる理由を次のように説明します。
- ストアドプロシージャはデータベースサーバーに保持されるため、非常に高速です。その理由は、1回だけコンパイルした後、もう一度コンパイルする必要がないためです。ただし、アプリケーション層で送信したSQLコードは、トランザクションごとに何度もコンパイルする必要があります。これは、複数のクライアントにサービスを提供する大規模なプロジェクトやサーバーにとっては大きな時間の無駄です。
- ネットワークトラフィックを大幅に節約できます。
- SQLステートメントに自動パラメーター化を提供します。 SQLステートメントが渡される場所ですべてのパラメーターを置き換える代わりに、SP内のパラメーターまたはルールのみを変更できます。これにより、アプリケーションをモジュール化できるようにするアプリケーションの複雑さも修正されます。
- ストアドプロシージャを作成するときに、プログラミング式（if、while、forなど）に加えてT-SQLコマンドを使用できます。
- ストアドプロシージャは、入力パラメータと出力パラメータのみがアプリケーション層に表示されるため、より信頼性が高くなります。データベースサーバーへのアクセスは通常、ユーザーIDとパスワードを使用して行われると考える場合、SPの使用はコードの信頼の要素であると言えます。
上記で頭に浮かんだストアドプロシージャの利点について説明しました。ほとんどすべてのソフトウェアアプリケーションは、通常、通常のSQLコードを使用していません。
上で述べたように、単一のポイントから管理され、複数の場所で使用され、他の人を簡単に見ることができないため、SPは非常に有利になります。
特にネットワークトラフィックについて考えると、ストアドプロシージャの名前を一度サーバーに送信するのではなく、クライアントからサーバーに送信されるSQLコマンドの行を多く送信することは、ネットワークトラフィックが非常に軽減されることを意味します。
ストアドプロシージャには4つのタイプがあります。
- システムストアドプロシージャ： それらはマスターデータベースにあり、 sp _ これらのストアドプロシージャにはプレフィックスが使用されます。これらは、データベースのシステム関連の管理ジョブで使用されます。
- ユーザーベースのストアドプロシージャ： これらのストアドプロシージャは、アプリケーションで使用されます。これらのSPは削除または変更できます。
- 拡張ストアドプロシージャ： 通常、これは.dllや、データベースサーバーの機能をコンパイルする一種のストアドプロシージャのようにコンパイルされます。マスターデータベースにのみ追加されます。
- CLRストアドプロシージャ： これは、任意の言語を使用してCLR環境で開発された一種のストアドプロシージャです。