低速化は cf と db の間の通信にあるため、クエリのクエリを呼び出す方がデータベースからのクエリよりも高速であるという考えがあります。これは本当ですか。
つまり、ループ内の QoQ は許容されますが、ループ内のクエリは許容されません。
低速化は cf と db の間の通信にあるため、クエリのクエリを呼び出す方がデータベースからのクエリよりも高速であるという考えがあります。これは本当ですか。
つまり、ループ内の QoQ は許容されますが、ループ内のクエリは許容されません。
完全な DBMS は [適切に作成された] クエリを処理するために高度に最適化されており、最新のネットワークではオーバーヘッドはそれほど大きくありません。
QoQ は組み込みデータベースを使用して実行されますが、実行されるクエリの種類に応じて、最適化されている場合とされていない場合があります。
そのため、データベースが低速のネットワークを介して別のマシンにある場合、状況によっては QoQ の速度が低下する可能性があります。データベースにヒットしている場合は、理想的には、1 回の要求ですべてを適切に処理し、ループでのラウンドトリップと再処理の両方を回避する必要があります。
もちろん、QoQ の大きな利点は、cfdirectory の結果やクエリに変換された CSV ファイルなど、データベース以外のデータを処理するために使用できることです。
ColdFusion は、手動で SQL を解析し、レコードセットをループすることで QoQ を実行します。これにより、一致するキーを使用した 2 つのテーブルの結合などの単純な操作では効率的になりますが、複雑な組み合わせ (結合が複数の列を使用する場合や、単純な a=b 比較ではない場合) では効率が低下します。(簡単な情報はこちら。)
Railo はH2を使用します。H2 は高速であると主張しており、彼らの Web サイトでは、Derby や MySQL よりも高速であることを示唆する速度比較を提供しています。パフォーマンス(たとえば、インデックスがないのではないかと思います)。
一般に、実際にパフォーマンスを改善する必要があるかどうかを判断し、どの方法が実際により高速であるかを客観的に判断できるようにするために、最初にパフォーマンス テストを行うことなく難しい決定を下さないでください。
それは、データベース サーバーと比較した Coldfusion マシンの機能と、解決しようとしている問題によって異なります。
QofQ は通常、小さなデータセットに対して非常に高速になります。これは、すべてサーバー メモリ内で行われるためです。ただし、大規模なデータセットで QofQ を使用しようとすると、そのデータをメモリに保持して処理するためのオーバーヘッドが原因で、サーバーに問題が発生し始めます。
データベース クエリは一般に、大規模なデータセットに対して QofQ よりも優れたパフォーマンスを発揮します。データベースは、大量のデータを非常に高速に処理するのに適しています。そのためにそれらを使用してください。
データベースから大量の結果セットを取得して QofQ で解析することを検討している場合、それはおそらく間違った方法です。代わりに、データベースに結果を減らしてもらいます。データベース サーバーにこの情報を頻繁に要求する場合は、サーバーにキャッシュします。
これはすべて主観的なものであり、特定の問題、負荷、データベース、およびサーバーの機能に大きく依存することに注意してください.
aq OF q を使用すると、クエリから DB を取得するよりもはるかに高速になることがわかりました。
たとえば、私は売上レポートで QoQ を宗教的に使用しています。第 1 四半期の日付範囲で取得される売上レポートがあります。このレポートには、販売代理店別の売上高と、販売された製品別の売上高が表示される場合があります。
私の DB では、同じレポートに表示される両方のセクションに同じテーブル/フィールドが使用されます。
日付範囲に基づいてデータのメイン テーブルをクエリし、次にそれらの結果をクエリして、レポートの各セクションを作成します。
DBローカルとリモートの両方のサーバーで、この方法の方が高速であることがわかりました。
QofQの利用時間
QofQを使用しない時間
詳細については、
http://help.adobe.com/en_US/ColdFusion/9.0/Developing/WSc3ff6d0ea77859461172e0811cbec0e4fd-7ff0.html
これはCF 9の場合ですが、QofQはCF 6以降ほぼ同じです
お前!cachedwithin を使用しました。