SQLインジェクション保護用ではありません。私はその利点を認識していますが、コンパイルされた部分とそれがより効率的である限り、それが効率のために利益をもたらすシナリオを見つけることができません。私はここでそれを望んでいました。漠然と知っているけど、ここ以外どこに聞いたらいいのかわからない。ありがとう。
質問する
87 次
2 に答える
0
シナリオは単純です: トランザクション処理です。
江戸官が言うように、ステートメントを準備すると、SQL をコンパイルして実行計画を作成するオーバーヘッドがなくなります。より複雑なクエリでは、このオーバーヘッドは最小限です。ただし、1 秒あたり 100 または 1000 のトランザクションを実行している場合、このオーバーヘッドがデータベースの効率的な使用を妨げる可能性があります。
もちろん、特に基になるテーブルの統計が変更された場合は、クエリ プランが最適ではない可能性があります。最適なクエリ プランを決定するために、準備時の特性が使用されます。これらは時間の経過とともに変化する可能性があり、別のクエリ プランの方が優れている可能性があります。これは、より複雑なクエリではより大きな問題です。これらは通常、実行に時間がかかるため、コンパイルのオーバーヘッドはそれほど問題になりません。
于 2012-08-16T18:35:57.850 に答える
0
準備済みステートメントのメリットを簡単に挙げることができます
- コンパイルのオーバーヘッドを取り除きます
- 実行計画を準備する必要がなくなります
- ステートメントではありませんが、ワイヤを介して移動する必要があるのはパラメーターのみであるため、帯域幅が得られます。
長い期間に何百万回も機能する 1 つのステートメントがある場合、そのすべての項目が効率にとって重要です。(ストアド プロシージャのように) 開発が容易であれば、それは有利な状況ですが...
「C with Embedded SQL」を使用してAS/400システムに直接接続するコードを開発しなければならなかったことがあります.CコードにSQLを記述し、それをプリプロセッサに渡してコンパイル可能なコードとバインダーファイルを出力し、バインダーファイルを渡します。 as/400 システムに送信して、ステートメントを準備します。すべては、サーバーへの ODBC サポートのインストールを拒否したためです。
そのコードを書いてテストするのは苦痛でした。動作が非常に遅く、何かを変更するとシステムが確実に壊れてしまいます。このようなコードを書くのは効率的ではありませんでした。
効率は、視点によって異なる変数に依存します。
私のサンプルでは、AS/400 の担当者は満足していました。なぜなら、 cr.pソフトウェアをインストールしないことでシステムの効率を維持できたからです。開発者に非効率的な方法でコードを書くように強制する彼らの方法は、タイムラインにそれを維持するのに十分効率的だったので、顧客は満足していました. 最小限のデータのみがネットワーク経由で送信されるため (メタデータがない場合でも)、ネットワーク管理者にとって効率的でした。時間がかかり、エラーが発生しやすいため、開発者にとって非常に非効率的でした。しかし、履歴書に「見栄えのする」ものを同じ開発者が取得することも効率的でした。
このように？
于 2012-08-16T14:52:42.177 に答える