静的SQLとの比較
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2022/02/19 20:02 UTC 版)
「ストアドプロシージャ」の記事における「静的SQLとの比較」の解説
オーバーヘッド ストアドプロシージャ文は直接データベースに格納されるため、ソフトウェアアプリケーションがインライン（動的）SQLクエリをデータベースに送信する状況で通常必要となるコンパイルのオーバーヘッドのすべてまたは一部を削除することができる。(ただし、ほとんどのデータベースシステムは、動的SQL文の反復的なコンパイルを避けるために、ステートメントキャッシュや他の方法を実装している)。また、プリコンパイルされたSQLをある程度回避できる一方で、SQL文のすべての引数がコンパイル時に提供されないため、最適な実行プランを作成するための複雑さが増す。特定のデータベースの実装や構成によっては、ストアドプロシージャと一般的なクエリやユーザー定義関数を比較した場合、性能に差が出ることがある。 ネットワークトラフィックの回避 ストアドプロシージャの大きな利点は、データベースエンジン内で直接実行できることである。本番システムでは、プロシージャは専用のデータベースサーバーで実行され、アクセスされるデータに直接アクセスできるのが一般的である。この利点は、ネットワーク通信コストを完全に回避できることである。これは、一連の複雑なSQL文の場合に、より重要になる。 ビジネスロジックのカプセル化 ストアドプロシージャは、プログラマがビジネスロジックをAPIとしてデータベースに埋め込むことができるため、データ管理を簡素化し、クライアントプログラムの別の場所でロジックをエンコードする必要性を低減することができる。その結果、欠陥のあるクライアントプログラムによるデータ破損の可能性を低くすることができる。データベースシステムは、ストアドプロシージャの助けを借りて、データの整合性と一貫性を確保することができる。 アクセス権の委譲 多くのシステムでは、ストアドプロシージャに、そのプロシージャを実行するユーザーが直接持っていないデータベースへのアクセス権を与えることができる。 SQLインジェクション攻撃からの保護 ストアドプロシージャは、インジェクション攻撃から保護するために使用することができる。ストアドプロシージャのパラメータは、攻撃者がSQLコマンドを挿入しても、データとして扱われる。また、DBMSによっては、パラメータの型をチェックするものもある。しかし、ストアドプロシージャが入力されたデータを使って動的SQLを生成する場合、適切な予防措置が取られない限り、SQLインジェクションの危険性があることに変わりはない。
※この「静的SQLとの比較」の解説は、「ストアドプロシージャ」の解説の一部です。
「静的SQLとの比較」を含む「ストアドプロシージャ」の記事については、「ストアドプロシージャ」の概要を参照ください。
- 静的SQLとの比較のページへのリンク
