ストアド プロシージャ (Stored Procedure) は、特定の関数用の SQL 文のセットであり、コンパイルされてデータベースに保存されます。ユーザーは、ストアド プロシージャの名前を指定し、パラメータを指定することによってストアド プロシージャを実行します (ストアド プロシージャにパラメータがある場合)。
1. ストアド プロシージャは、作成時にのみコンパイルされます。今後、ストアド プロシージャを実行するたびに再コンパイルする必要はありません。一般に、SQL ステートメントは実行されるたびに 1 回コンパイルされるため、ストアド
プロシージャを使用するとデータベースを改善できます。実行速度
。
2. データベースに対して複雑な操作(
複数のテーブルに対する更新、挿入、クエリ、削除など)を実行する場合、この複雑な操作結果の保存処理をカプセル化し、
データベースが提供するトランザクション処理と組み合わせて使用できます。
3. ストアドプロセスを再利用できるため、データベース開発者の負担を軽減できます
4. セキュリティが高く、指定したストアドプロセスを特定のユーザーのみが使用できるように設定できます
1
2
3
4
5
6
7
8
SQL文を使用して、アプリケーション内でストアドプロシージャを直接呼び出すことには、次の利点があります:
(1) ネットワークトラフィックを削減します。
行数の少ないストアドプロセスを呼び出す場合のネットワークトラフィックは、SQL文を直接呼び出す場合とそれほど変わらないかもしれませんが、ストアドプロセスに数百行のSQL文が含まれる場合、その機能は確実に低下します。 SQL 文を 1 つずつ呼び出します。
(2) フルフィルメントがより速くなります。
理由は 2 つあります。1 つは、ストアド プロシージャの作成時に、データベースがすでに一度分析して最適化していることです。次に、ストアド プロセスが実行されると、ストアド プロセスのコピーがメモリに保存されるため、次回同じストアド プロセスを実行するときにメモリから直接呼び出すことができます。
(3) より強い適応力。
ストアド プロセスはストアド プロセスを介してデータベースにアクセスするため、データベース開発者はストアド プロセスのインターフェイスを変更せずにデータベースに変更を加えることができ、これらの変更はアプリケーションには影響しません。
(4) 分散ジョブ。
アプリケーションプログラムとデータベースのコーディング作業は、相互に制約を受けることなく独立して行うことができます。
短所:
1. 変更が入力ストアド プロセスのパラメータの変更を必要とするほど大きい場合、またはストアド プロセスから返されるデータを変更する必要がある場合でも、アセンブリのコードを更新してパラメータを追加し、GetValue() 呼び出しを更新する必要があります。 , など、現時点ではさらに煩雑になると推定されます。
2. 低い移植性
ストアド プロセスはアプリケーションを SQL Server にバインドするため、ストアド プロセスを使用してトランザクション ロジックをカプセル化すると、アプリケーションの移植性が制限されます。
Oracle データベースでストアド プロシージャができることについて話していますか? メリットは何ですか?デメリットは何ですか?
おすすめ
転載: blog.csdn.net/linwei_hello/article/details/90779060
ランキング