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

Существует 5 причин использовать SelectQuery

• Вы создаете динамические запросы с различным количеством условий, объединений, полей и т. д. См. field_read_fields () для примера.

• Вы хотите использовать так называемые Расширители . Примерами расширения являются PagerDefault (заменяет pager_query () ) и TableSort (заменяет tablesort_sql () ). Они позволяют добавлять дополнительные функции в SelectQuery. См. Также Как сделать сортируемые таблицы с пейджером с данными из пользовательской таблицы? . Пример: node_page_default () .

• Вы хотите разрешить другим модулям изменять ваши запросы. Затем вы можете добавить так называемый теги и SelectQuery автоматически вызовет соответствующий перекрестный крючок для этого тега. Я сильно полагаюсь на это с помощью моего модуля Privatemsg (мы уже сделали это в D6 с помощью настраиваемого построителя запросов).

• Если вам нужно /нужно использовать систему node_access, чтобы показывать только узлы, которые пользователь может видеть. Просто добавьте тег 'node_access' в ваш $ query. Это заменяет db_rewrite_sql ().

• В SelectQuery есть несколько функций, которые помогают сделать ваш код одинаковым для всех поддерживаемых баз данных. Например, есть SelectQuery: : orderRandom () . И если у вас есть условие LIKE, -> условие ('field', $ value, LIKE), убедитесь, что это всегда нечувствительное к регистру сравнение. В D6 вам пришлось использовать LOWER () для того, что было намного медленнее. Но AFAIK, сейчас их не больше двух.

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

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

  

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

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