17

アドホック クエリとストアド プロシージャと動的 SQL。長所と短所を言える人はいますか？

4

6 に答える 6

31

ストアド プロシージャ

  • 長所: 短くて単純なクエリ (別名 OLTP -- つまり、レコードの追加、更新、削除、表示) に適しています
  • 長所: データベース ロジックをビジネス ロジックから分離しておく
  • 長所: トラブルシューティングが容易
  • 長所：メンテナンスが簡単
  • 長所: ネットワーク経由で転送されるビットが少ない (つまり、proc 名とパラメーターのみ)
  • 長所: データベースにコンパイル
  • 長所: セキュリティの向上 (ユーザーがテーブルに直接アクセスする必要がない)
  • 長所: 優れたクエリ プランのキャッシュ ( OLTPクエリに適しています。プランの再利用によるメリットがあります)
  • 短所: 優れたクエリ プランのキャッシュ ( OLAPクエリには不向き - 独自のプランの利点)
  • 短所: その SQL ベンダーに縛られる

動的 SQL (つまり、ストアド プロシージャ内で exec コマンドを使用する)

  • 長所: 短くて単純なクエリ (別名 OLTP) に適しています。
  • 長所: データベース ロジックをビジネス ロジックから分離しておく
  • 長所: ネットワーク経由で転送されるビットが少ない (つまり、proc 名とパラメーターのみ)
  • 長所: 任意のテーブル、データベース、または列を参照できます
  • 長所: 述語 (WHERE 句内) をパラメーターに基づいて追加/削除できるようにする
  • 長所: 優れたクエリ プランのキャッシュ (OLTP クエリと OLAP クエリの両方で平凡から適切)
  • 短所: proc の静的要素のみをコンパイルできます。
  • 短所: その SQL ベンダーに縛られる
  • 短所: トラブルシューティングがより困難
  • 短所: SQL インジェクション攻撃に対してより脆弱

アドホック SQL (つまり、ビジネス コードで作成)

  • 長所: 長くて複雑な quieres (別名 OLAP -- つまり、レポートまたは分析) に適しています。
  • 長所: 柔軟なデータ アクセス
  • 長所: ORM の使用が可能です。コードでコンパイル/テスト可能 (つまり、Linq-to-Sql または SqlAlchemy)
  • 長所: クエリ プランのキャッシングが不十分 ( OLAP クエリに適しています。独自のプランのメリットがあります)
  • 短所: クエリ プランのキャッシングが不十分です ( OLTPクエリには不向きです。プランの再利用によるメリットがあります)。
  • 短所: ネットワーク経由でより多くのビットが転送されます (つまり、クエリとパラメーター全体)。
  • 短所: ORM を使用しない場合、保守がより困難になります。
  • 短所: ORM を使用しないと、トラブルシューティングが難しくなります。
  • 短所: SQL インジェクション攻撃に対してより脆弱

注: 常にアドホック SQL をパラメーター化してください。

OLAP アドホック SQL の場合: 文字列データのみをパラメータ化します。これは2つの条件を満たしています。SQL インジェクション攻撃を防ぎます。また、クエリがデータベースに対してよりユニークに見えるようになります。はい、クエリ プランのキャッシュ ヒット率は低くなります。しかし、これは OLAP クエリにとって望ましいことです。彼らのデータセットと最も効率的な計画は、与えられたパラメータによって大きく異なるため、独自の計画生成の恩恵を受けます。

于 2010-05-29T10:33:59.980 に答える
2

ストアド プロシージャの長所:

  • 編集済み。これは、最初の実行以外のすべての最適化/コンパイル段階をバイパスするため、実行が高速であり、データベース サーバーの CPU にプラスの影響を与えることを意味します。
  • 複雑な読み取りおよび書き込みクエリに対する明確なアクセス許可制御を可能にします。
  • samke クエリを再実装し、非効率的な実装を取得するリスクを冒すさまざまなアプリからのさまざまなプラットフォーム上の多数の Yahoo ではなく、1 つの優れた効率的な実装を可能にする再利用可能な API を提供します。
  • 他の API と同様に、抽象化レイヤーを提供します。SP を呼び出すコードを変更せずに、基になる実装 (スキーマ) を変更できます。クエリを使用するすべてのプラットフォームに何百ものアプリがある場合、これは非常に大きなプラスです。

ストアド プロシージャの短所:

  • 動的 SQL と比較して柔軟なロジックをコーディングするのは難しい
  • 事前にコンパイルされたバージョンを使用すると、データがドリフトし、オプティマイザーの選択が変化するため、実行の効率が低下する可能性があります。これは、時々再コンパイルすることで簡単に改善できます。
于 2010-05-29T10:48:58.323 に答える
0

ストアド プロシージャ

  • 長所: テーブル レベルでより基本的な権限を付与する必要のないアクションの許可。
  • 長所: ディスクリートでバージョン管理可能
  • メリット: スキーマをデータ アクセス コードから分離できます。
  • 短所: CRUD プロシージャのコーディングが面倒になる可能性がある
  • 短所: 基礎となるスキーマに合わせて維持する必要がある

その場しのぎで動的 - Bill Paetzke の回答とコメントを参照してください。

また、リストにはないが考慮すべき SQL の一括挿入などのパターンも忘れないでください。

于 2010-05-29T10:47:09.917 に答える
0

RDBMS? この回答は古いオラクルに固有のものです

古い Oracle バージョン < 11 では、動的 SQL は既存の SGA sqltext プランを再利用せず、パーサーが必要とする実行プランごとに新しいエントリを作成します。多くの動的SQL呼び出しでは、sqltext領域が十分に高速にフラッシュされるため、クエリの再利用が大幅に低下し、パフォーマンスが低下します。

于 2010-05-29T14:39:41.980 に答える
0

追加の利点の 1 つは、「ダウンタイムなしのアップグレード」が容易であることです (メジャー アップグレードの場合、ダウンタイムが発生する可能性があります)。

すべてのデータ アクセスがストアド プロシージャを介して行われる場合、ストアド プロシージャの v1 と v2 を簡単に並べて配置できます。

v1 と v2 のバイナリ/アプリケーション ロジックを並行して実行し、それぞれが独自のバージョンのストアド プロシージャを呼び出すことができるようになりました。

1、v1 アプリを読み取り専用モードにロックダウンする (該当する場合)、2、データベースの変更をデプロイすることにより、ダウンタイムは発生しません。3、v1 アプリへの通常のアクセスを再度有効にします。4、v2 アプリを並べて展開し、新しいユーザーに新しいバイナリを使用するように指示します。6. 古いバイナリを使用するユーザーがいなくなったら、古いバイナリをシャットダウンします。

于 2012-08-02T15:50:26.803 に答える
0

私見ストアド プロシージャは疫病のように避ける必要があります。これらを絶対に使用してはならない理由として、私の頭の中で考えられる 10 の正当な理由を次に示します (すべてのデータベースに適用されます)。

  1. PL/SQL 言語は、テーブル、行、および列のデータを処理することを目的としています。これは、ビジネス ロジックを表現するための適切な選択ではありません。どんな言語でも何でもコーディングできます - それはあなたがすべきだという意味ではありません
  2. ほとんどのデータベースには、構文や他の既存の手順へのリンクを支援する適切な IDE がありません (たとえば、Eclipse が Java に対して行っているように)。
  3. ストアド プロシージャを作成および維持する人材を見つけるのは困難です。単純に、ストアド プロシージャは非常にまれであり、そのためコストが高くなります。
  4. a) PL/SQL の業界標準がない b) 標準があったとしても、通常はストアド プロシージャ内でデータベース固有の機能/SQL を使用することになるため、ストアド プロシージャはデータベース間で移植できません。データベースを移動する必要がある場合は、ビジネス ロジックを完全に書き直す必要があります。
  5. ほとんどのデータベースは、ストアド プロシージャのデバッグをサポートしていません。ログ テーブルなどに行を挿入して、デバッグ用のログを取得する必要があります。非常に見苦しいです。
  6. ストアド プロシージャをテストするには、実際のデータベース インスタンスが必要です。これにより、ストアド プロシージャの単体テストが難しくなります (それらを実行するには、それらを開発データベースにデプロイする必要があります)。
  7. ストアド プロシージャをデプロイするには、データベースを更新する必要があります (ストアド プロシージャをドロップしてから作成します)。バグが発見された場合、アプリ コードの場合のように単純に以前のバイナリ リリースにロールバックすることはできません。代わりに、古いコードを見つけて、新しいストアド プロシージャを削除し、古いものを (再) 作成する必要があります。これは変更の上にある変更であり、ロールバックではありません
  8. ビジネス ロジックを他の (アプリ) サーバーに分散するのではなく、データベース サーバーの処理要求を増やしています。データベースは通常シングルトンであるため、これは非常に悪いことです。容量を増やす唯一の方法は、より優れたハードウェアを購入することです (追加のハードウェアを購入したり、クラウドを使用したりするのではありません)。
  9. これらは、準備済みステートメントを使用して適切に作成されたクエリよりもそれほど高速ではありません。これは、データベース サーバーでの処理要求の増加と、それらを使用する効率との間にトレードオフがあるためです。さらに、速度がすべてではありません (許容できる限り): 保守性、デバッグ可能性、PL/SQL の適合性などは、それ以上ではないにしても、それと同じくらい重要です。
  10. ストアド プロシージャ言語では、利用できるライブラリが (あるとしても) 限られているため、価値の低いコードを大量に作成することになります。これは、ビジネス ロジックに必要なすべてのものに使用できるライブラリが多数あるアプリ言語とは異なります。

私がそれらの使用を許可する場所は 1 つだけです: 非常に特定のデータベース機能 - おそらくキー チェックやデータ型変換など、おそらくトリガー内で、これは非常に重要であり、その存在が正当化され、おそらく今後も使用されることはありません。一度書いたら変更。

一般に、ストアド プロシージャから叫んで実行する必要があります。

于 2013-01-25T09:20:34.343 に答える