CF — ​​QoQ и запрос

Полные СУБД высоко оптимизированы для обработки [соответствующим образом написанных] запросов, и в современной сети накладные расходы не будут огромными.

QoQ выполняется с использованием встроенной базы данных, которая может быть оптимизирована или нет, в зависимости от типа выполняемого запроса.

Таким образом, если база данных находится на другом компьютере в медленной сети, в некоторых ситуациях QoQ может быть менее медленным. Если вы вообще обращаетесь к базе данных, в идеале вы хотите, чтобы все обрабатывалось там надлежащим образом, в одном запросе, и избегало как двусторонних обращений, так и повторной обработки в цикле.

Конечно, большим преимуществом QoQ является то, что вы можете использовать его для обработки данных, которые не поступают из базы данных, таких как результаты cfdirectory или CSV-файл, преобразованный в запрос.

ColdFusion выполняет QoQ, вручную анализируя SQL, а затем циклически перебирая набор записей. Это делает его эффективным для простых операций, таких как объединение двух таблиц с соответствующими ключами, но менее эффективным для сложных комбинаций (где объединение использует несколько столбцов и/или не является прямым сравнением a=b). (краткая информация здесь.)

Railo использует H2. H2 утверждает, что работает быстро, и на их веб-сайте есть несколько сравнений скоростей, которые предполагают, что он быстрее, чем Derby и MySQL - но, конечно, было бы лучше поискать независимые сторонние тесты, не говоря уже о том, что эти тесты не являются гарантией производительности QoQ (у которой, я подозреваю, например, не будет индексов).

В целом: не принимайте жестких решений без предварительного тестирования производительности, чтобы определить, что вам действительно нужно улучшить производительность, и иметь возможность объективно определить, какой метод на самом деле быстрее.

Это зависит от возможностей вашей машины Coldfusion по сравнению с вашим сервером базы данных и проблемы, которую вы пытаетесь решить.

QofQ, как правило, будет очень быстрым для небольших наборов данных, потому что все это происходит в памяти вашего сервера. Если вы попытаетесь использовать QofQ для большого набора данных, у вашего сервера начнутся проблемы из-за накладных расходов, связанных с хранением и обработкой этих данных в памяти.

Запросы к базе данных обычно превосходят QofQ на больших наборах данных, потому что именно для этого они предназначены. Базы данных хороши для быстрой обработки больших объемов данных. Используйте их для этого.

Если вы планируете получить большой набор результатов из базы данных и проанализировать его с помощью QofQ, это, вероятно, неправильный способ сделать это. Вместо этого заставьте базу данных уменьшить результаты для вас. Если вы часто запрашиваете у сервера базы данных эту информацию, кэшируйте ее на своем сервере.

Имейте в виду, что все это субъективно и во многом будет зависеть от вашей конкретной проблемы, нагрузки, базы данных и возможностей сервера.

Я обнаружил, что использование q OF q может быть НАМНОГО быстрее, чем извлечение БД из запроса.

Например, я неукоснительно использую QoQ в отчетах о продажах. У меня есть отчет о продажах, который будет извлечен для диапазона дат 1-го квартала, который может отображать данные о продажах по агентам по продажам, а также может отображать данные о продажах по проданным продуктам.

В моей БД одни и те же таблицы/поля будут использоваться для обоих разделов, которые будут отображаться в одном и том же отчете.

Я запрашиваю основную таблицу для своих данных на основе диапазона дат, а затем запрашиваю эти результаты для построения каждого раздела моего отчета.

Я обнаружил, что этот метод был быстрее на обоих серверах с локальной и удаленной БД.

Время использования QofQ

• Когда у вас есть два источника данных и по разным причинам вы можете использовать связанные серверы
• Когда данные поступают через WDDX или JSON, и вам нужно выполнить соединение
• Когда целесообразно хранить данные в кэшированном запросе и выполнять QofQ для кэшированного запроса
• Когда вам нужно объединить результат directoryList() с базой данных

Время не использовать QofQ

• Когда вместо этого вы можете загрузить данные в структуру
• При выполнении большого количества итераций
• Когда один из наборов исходных данных очень большой
• Когда вам нужно сделать левое, правое или внешнее соединение

Подробнее см.

http://help.adobe.com/en_US/ColdFusion/9.0/Developing/WSc3ff6d0ea77859461172e0811cbec0e4fd-7ff0.html

Это для CF 9, но QofQ был примерно таким же, как и CF 6.

Чувак! Просто использовал cachedwithin.