Учитывая, что db_select намного медленнее, чем db_query, зачем мне его использовать?

69

Информацию об этом см. На странице http://drupal.org/node/1067802 .

Учитывая все это, в каких ситуациях я мог бы использовать db_select () или я должен полагаться исключительно на db_query?

7 performance database

— Крис Коэн
источник

88

Есть 5 причин использовать SelectQuery

Вы создаете динамические запросы с различным количеством условий, объединений, полей и так далее. Смотрите field_read_fields () для примера.
Вы хотите использовать так называемые расширители . Примерами экстендеров являются PagerDefault (заменяет pager_query () ) и TableSort (заменяет tablesort_sql () ). Это позволяет добавить дополнительные функции в SelectQuery. См. Также Как создавать сортируемые таблицы с помощью пейджера с данными из пользовательской таблицы? , Пример: node_page_default () .
Вы хотите, чтобы другие модули могли изменять ваши запросы. Затем вы можете добавить так называемые теги, и SelectQuery автоматически вызовет соответствующий крюк alter для этого тега. Я сильно полагаюсь на это с моим модулем Privatemsg (мы уже делали это в D6 с помощью специального построителя запросов).
Если вы хотите / должны использовать систему node_access, чтобы показывать только узлы, которые пользователь может видеть. Просто добавьте тег 'node_access' в ваш запрос $. Это заменяет db_rewrite_sql ().
SelectQuery имеет несколько функций, которые помогают сделать ваш код одинаковым для всех поддерживаемых баз данных. Например, есть SelectQuery :: orderRandom () . И если у вас есть условие LIKE, -> условие ('field', $ value, 'LIKE') гарантирует, что это сравнение будет всегда без учета регистра. В D6 вы должны были использовать LOWER () для того, что было намного медленнее. Но AFAIK, не больше, чем эти два прямо сейчас.

Если ни одна из этих причин не подходит для конкретного случая, используйте db_query ().

— Berdir
источник

1

Добавлен пятый пункт - функции переносимости базы данных, такие как orderRandom () и LIKE без учета регистра.

— Бердир

6

В качестве шестой причины я бы добавил совместимость с базами данных. Например, запросы Oracle имеют синтаксис, который в некоторых отношениях отличается от MySQL, Postgres и т. Д. Гораздо проще написать код для генерации правильного синтаксиса из db_select (), чем это может быть, когда какой-то не очень совместимый с Oracle код запроса сбрасывается непосредственно в db_query ().

— BrianV

9

Документация оdb_query() говорит:

Используйте эту функцию для запросов SELECT, если это просто строка запроса. Если вызывающий или другие модули должны изменить запрос, используйте взамен db_select ().

— marcvangend
источник

Спасибо, но это не совсем точно. Это оставляет определение «простой строки запроса» достаточно открытым для интерпретации. Если я выбираю 4 таблицы с 6 объединениями, это все еще простой запрос, или вместо этого он должен выполняться с помощью db_select ()?

— Крис Коэн

3

Речь идет не о «простом запросе», а о «простой строке запроса », а простой означает жестко закодированный, а не динамический. Смотрите мой ответ для более подробной информации :)

— Бердир

9

Я всегда использую db_select, поскольку предпочитаю удобочитаемость, удобство обслуживания и совместимость с базами данных, а не небольшой выигрыш в производительности. Более того, я думаю, что цифры, приведенные в упомянутой проблеме, дают неправильное представление об общей производительности. Мы говорим о разнице в 300 микросекунд в запросе, который при возврате более одного столбца часто выполняется в диапазоне нескольких миллисекунд. И я не удивлюсь, если есть одноразовые накладные расходы (загрузка классов) и, таким образом, различия для полного запроса (страницы) намного меньше.

— fietserwin
источник

Разница в производительности не так проста; см. Сравнение производительности db_query и db_select . Я обычно рекомендую db_query вместо db_select, если вам не нужна одна из специальных функций, упомянутых в ответе Бердира.

— geerlingguy