a) 動的 SQL ステートメントとは何ですか?
句または句の一部だけを SQL 文字列に動的に追加する SQL ステートメントはありますか?
b) 動的に提供される値のプレースホルダーを使用するパラメーター化された文字列も、動的 SQL ステートメントと見なされませんか?
ありがとう
9 に答える
6
動的 SQL ステートメントは、実行時に作成されるステートメントです。ステートメントに重点が置かれています。したがって、実行時に値を指定するだけでは、動的 SQL ではありません。
于 2009-12-10T20:26:29.697 に答える
3
確かにEXEC (@sql)or EXEC sp_ExecuteSQL @sql, ...(つまり、データベース自体で動的) を含むものはすべて資格がありますが、(ビルド/インストール時に修正されるのではなく) 実行時に生成される SQL は資格があると主張できると思います。
そうです、実行時に生成されたが正しくパラメーター化されたクエリは "動的" (たとえば、LINQ-to-SQL で生成されたクエリ) であると主張できますが、正直に言うと、インジェクション攻撃にさらされない限り、私は名前は気にしないでください;-p
于 2009-12-10T20:27:24.860 に答える
3
動的 SQL ステートメントは、通常、文字列連結を使用して構築されたものを指します。
"SELECT name FROM names WHERE id=" + this.id;
"SELECT name FROM names WHERE id=" + this.id + " AND age=" this.age;
パラメーター化されたクエリも動的ですが、構造に関してはそうではありません。パラメータのみを変更できますが、ステートメントの構造を変更することはできません。つまり、WHERE句を追加することはできません。
多くの場合、パラメーター化されたクエリはデータベース レベルで行われるため、データベースはクエリの実行プランをキャッシュし、何度も使用できます。テキストまたは where 句の順序の単純な変更により、データベースが以前にキャッシュされた実行プランを認識せず、最初からやり直す可能性があるため、最初のケースではまったく不可能です。
不正な SQL を注入しようとする試みに対して入力値を検証するのが難しいため、最初の構造も SQL インジェクションに対して脆弱です。
于 2009-12-10T20:27:39.203 に答える
2
動的SQLは基本的に、実行時まで完全に構築されていないSQLです。ランタイム値をステートメントに連結することにより、オンザフライで生成されます。SQL ステートメントの任意の部分である可能性があります
于 2009-12-10T20:28:58.000 に答える
1
A. DB サーバーが文字列を SQL として評価する原因となるもの。
B. いいえ、DB ドライバー/プロバイダーを通過してクリーンアップされるためです。
于 2009-12-10T20:27:28.290 に答える
1
ポイント b) については、ステートメントを既に知っており、既知のパラメーターを渡します (できれば、文字列リテラルではなく、タイプ セーフです)。
于 2009-12-10T20:27:50.077 に答える
1
私はあなたがこれでどこに向かっているのか分かりますが、特定の状況を動的 SQL 対準備済みステートメントと定義するやや客観的な基準の 1 つは...
...動的ステートメントにより、SQLサーバーがクエリを完全に評価し、クエリプランを定義するなどの事実。
準備済みステートメントを使用すると、SQL は (明示的に要求されない限り) クエリ プランをキャッシュできます (場合によっては、戻り値などに関する統計を収集することさえできます)。
[編集: 事実上、動的 SQL ステートメントでさえもキャッシュされますが、そのようなキャッシュされたプランは再利用される可能性がはるかに低くなります。これは、まったく同じクエリを新たに受け取る必要があるためです (プランが再利用されるパラメーター化されたクエリとは異なります)もちろん、「WITH RECOMPILE」でない限り、個別のパラメーター値を使用）]
したがって、質問の場合、a) と b) の両方が動的 SQL と見なされます。b) の場合、置換は SQL の外部で行われるためです。これは準備済みステートメントではありません。SQL は、単に検索値を変更していることを認識しないため、これをまったく新しいステートメントと見なします。
さて...動的SQLのSQL中心の定義を超えて、a)とb)のケースなど、さまざまな形式の動的SQLを区別すると役立つ場合があります。
動的 SQL は、SQL インジェクションの認識に関連して、しばらくの間悪い評価を受けてきました。動的 SQL が ストアド プロシージャ内で生成および実行されるアプリケーションを見てきましたが、技術的には "SQL 側" であるため、一部の人々はそれを受け入れる傾向がありました (特に SQL インジェクションは対処されていない可能性があります)。 ..
ここで言いたいのは、さまざまなコンテキスト要素からクエリを動的に構築することがしばしば必要になるということであり、これを「アプリケーション」層に実装することをお勧めします (アプリケーション側の層と呼びます。実際、アプリケーション自体から分離することができ、分離する必要があります)。プログラミング言語と関連するデータ構造は、通常、T-SQL などよりも簡単で表現力豊かです。私の意見では、これを「データ側」と呼ぶために SQL に詰め込むのは良いことではありません。
于 2009-12-10T20:29:39.090 に答える
1
動的 SQL ステートメントとは、実行時に新しい値を受け入れて、別の結果を返すステートメントであると考えています。私の推測では、「新しい値」は、異なる ORDER BY、新しい WHERE 基準、異なるフィールド選択などである可能性があります。
于 2009-12-10T20:30:54.713 に答える
1
a) 動的 SQL ステートメントとは何ですか? 句または句の一部だけを SQL 文字列に動的に追加する SQL ステートメントはありますか?
両方 - 実行前に変更/調整されたクエリ。
b) 動的に提供される値のプレースホルダーを使用するパラメーター化された文字列も、動的 SQL ステートメントと見なされませんか?
パラメータ化されたクエリ (別名バインド変数を使用) は、クエリにさまざまなフィルター基準を提供しています。を使用できます(my_variable IS NULL OR ...)が、OR のパフォーマンスは通常、どのデータベースでもひどいものであり、このアプローチは sargability を破壊します。
動的 SQL は通常、特定のパラメーターが設定されている場合にのみ含める必要がある JOIN など、他のロジックを含めるようにクエリを調整します。ただし、オプションのリストであるコンマ区切り文字列の変換をサポートしていない IN 句などの制限があります。このためには、動的 SQL を使用するか、別の方法でコンマ区切りリストを処理する必要があります (一時テーブルにパイプライン化された CLR、等）。
于 2009-12-10T20:47:44.513 に答える