0

次の Coldfusion/MySQL クエリで何が起こっているのかを理解しようとしていますが、更新する必要があります (CF/MySQL を使い始めて 1 か月目です)。

検索の前にクエリを実行しています。これにより、変数pl (pricelists) が次のように設定されます。

<cfif variables.module IS "yes"> 
  <cfquery datasource="ds" name="qp">
      <!--- selects pricelist and seller --->
  </cfquery>
  <cfset variables.pl = "LEFT JOIN pricelist p ON ">
  <cfoutput query="qp" >
    <cfif qp.preislist IS ''>
        <cfset variables.pl= variables.pl & '(p.iln = a.iln AND p.preislist = "AAA" AND p.ean = a.ean AND p.iln = "#qp.seller#") OR '>
    <cfelse>
        <cfset variables.pl= variables.pl & '(p.iln = a.iln AND p.preisliste = "#qp.preislist#" AND p.ean = a.ean AND p.iln = "#qp.seller#") OR '>
    </cfif>
  </cfoutput>
  <cfset variables.pl = variables.preislisten & "(1=0)">
</cfif>

これは検索クエリに「移植」され、次のように混乱を招きます。

<cfquery datasource="ds" name="getArt">
    SELECT a.* <cfif variables.module IS "yes">, p.ek, p.vk, p.waehrung, p.onlinepreis</cfif>
    FROM artdata a
    <cfif variables.module IS "yes">
        <cfqueryparam cfsqltype="cfsql_varchar" value="#variables.pl#"> 
    </cfif>
    ....

多くの質問: - qp.seller などのフィールドをcfparam
クエリする必要はありませんか、それともありますか? - artdata AS a の ように常に ALIAS を使用するのではなく、artdata aのみを使用するべきではありませんか? - p.ek、p.vk、...をこのように選択できますか? ただし、pricelist テーブルは後で変数variables.plを介してのみ宣言されます( LEFT JOIN pricelist p ON ...) - どうしたのですか? 1=0)? その目的は何ですか?(3=2)、(1=2) のディト。


啓発をありがとう!

4

3 に答える 3

3

qp.sellerなどのcfparamクエリフィールドは必要ありませんか、それともありますか?

cfparamではなくcfqueryparamです。これらは異なるタスクを実行する2つの異なるタグです。

cfqueryparamを使用する主な理由は2つあります。

1)セキュリティのため-入力が元々サードパーティからのものである可能性がある場合、または入力が既知の値であることを保証できない場合は、cfqueryparamを使用して、SQLコードインジェクション(意図的または偶発的)が発生しないようにします。

2)パフォーマンスの場合-クエリパラメータは、キャッシュして複数のクエリに適用できる実行プランを生成します(つまり、パラメータが変化する場合)。したがって、多くの場合、パフォーマンスが向上します。

qp.sellerが安全性が保証されている数値外部キーである場合、セキュリティのためにそれは必要ありませんが、それでもパフォーマンスの観点から有益な効果がある可能性があります。

一般的に、疑わしい場合はそれを使用してください。

(実行計画が不適切でパフォーマンスが低下すると主張する人もいますが、私はそれらの主張に注意しており、いずれの場合もケースバイケースで対処する必要があります-セキュリティは重要です。)


artdata AS aのようにALIASを常に使用するのではなく、artdata aのみを使用するのではないでしょうか?

もっと入力したい場合。:)

テーブル名のASキーワードに違い/利点はありません。


p.ek、p.vk、...をこのように選択できますか

うん、それはうまくいくだろう。

読みやすくするために、複数行に配置することをお勧めします。


ただし、価格表テーブルは、後で変数> variables.pl(LEFTJOIN価格表pON ...)を介してのみ宣言されます。

これは間違った仮定です。

cfqueryparamを使用すると、SQLコードが挿入されなくなります。これは、ここで実行しようとしていることです。

variables.plを作成する代わりに、この生成されたSQLを使用されるcfqueryタグに直接出力する必要があります。

(私が何を意味するのかわからない場合は、この例を実行できますか?)


(1 = 0)はどうしたの?それの目的は何ですか?(3 = 2)、(1 = 2)のディト。

Romainのコメントで説明されているように、これはfalseと言う一般的な方法であり、動的クエリがある場合に使用されます。括弧はオプションです。

ただし、最初に(つまり、または)配置し、その後で動的ステートメントを開始するのがより一般的です。WHERE 1=0JOIN 1=0OR ...

于 2012-05-21T12:53:09.627 に答える
2

-qp.sellerなどのcfparamクエリフィールドは必要ありませんか、それともありますか?

まず、これはcfqueryparam、ではありませんcfparamcfqueryparamデータのサニタイズ用です。cfparamある種の値を持つ変数が存在することを確認するためのものです。使う必要はありますか?明示的にvariables.plを作成/設定している場合は、いいえ。しかし、それでも良い習慣です。データをcfqueryparam-ingすると、後で設定コードを変更した場合でも、データの整合性が保証されます。また、変数が保持しているデータの種類を一目で知るのにも役立ちます。

--artdata AS aのように常にALIASを使用するのではなく、artdata aのみを使用する必要がありますか?

私が理解しているように、あなたはそうすべきです。私が使用したすべてのデータベースはtablename alias構文をサポートしていますが、ANSI規格ではAS、コードをより移植性の高いものにするためにを使用することになると思います。

-p.ek、p.vk、...をこのように選択できますが、価格表テーブルは後で変数variables.pl(LEFTJOIN価格表pON ...)を介してのみ宣言されます。

はい。これはかなり一般的です(少なくとも私が働いている場所では)。

-(1 = 0)はどうしたの?それの目的は何ですか?(3 = 2)、(1 = 2)のディト。

これはRomainによるコメントでよく答えられました。これは強制的にtrue/falseの値です。これは、SQLステートメントをその場で生成するときに、少なくとも1つのWHERE句が生成されるようにするためによく使用されます。

于 2012-05-21T12:58:37.710 に答える
2

「qp.seller などのフィールドに cfparam クエリを実行する必要はありませんか?」について: まだ言及されていないことの 1 つは、cfqueryparam が cfquery タグのコンテキスト内でのみ有効であるという事実です。cfquery タグ コンテキストの外部で SQL ブロックを作成しているため、そこで qp.seller に cfqueryparam を使用することはできません。したがって、いくつかの選択肢があります-

  1. SQL コードを cfquery ブロックに移動し、cfqueryparam を使用します。
  2. qp.seller を引数として受け取るストアド プロシージャまたは関数をデータベースに作成します。
  3. #qp.seller# が有効な値であることを確認するには、ある種のデータ検証正規表現を使用します。
  4. 何もせず、クエリへの入力として使用されるデータのソースを制御できるため、SQL インジェクションを心配する必要はないと信じてください (ただし、パフォーマンスの向上の可能性は失われます)。 .

他のポスターはあなたの他の質問に十分に答えています - 私はそれらに追加するものは何もありません.

于 2012-05-21T17:27:45.017 に答える