Зважаючи на те, що 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 (замінює tableort_sql () ). Вони дозволяють додатково додати функціональність до SelectQuery. Див. Також Як створювати сортувальні таблиці з пейджером із даними із користувацької таблиці? . Приклад: node_page_default () .
Ви хочете дозволити іншим модулям змінювати ваші запити. Потім ви можете додати так звані теги, і SelectQuery автоматично зателефонує до відповідного гачка для цього тегу. Я сильно покладаюся на це з моїм модулем Privatemsg (ми вже це робили в D6 зі спеціальним конструктором запитів).
Якщо ви хочете / потрібно використовувати систему node_access, щоб показувати лише вузли, яким користувач може бачити. Просто додайте тег "node_access" до вашого $-запиту. Це замінює db_rewrite_sql ().
SelectQuery має кілька функцій, завдяки яким ваш код працює однаково у всіх підтримуваних базах даних. Наприклад, є SelectQuery :: orderRandom () . І якщо у вас є умова LIKE, -> condition ('поле', $ value, 'LIKE') переконається, що це порівняння завжди нечутливе до випадків. У D6 вам довелося використовувати LOWER () для того, що було набагато повільніше. Але AFAIK, наразі не більше двох цих.

Якщо жодна з цих причин не стосується конкретного випадку, використовуйте db_query ().

— Бердір
джерело

1

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

— Бердір

6

Як шоста причина, я б додав сумісність міжбазових баз даних. Наприклад, запити Oracle мають синтаксис, який дещо відрізняється від MySQL, Postgres тощо. Написати код набагато простіше для створення правильного синтаксису з db_select (), ніж це може бути, коли якийсь не дуже сумісний з оракулом код запиту скидається безпосередньо в 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