Biorąc pod uwagę, że db_select jest znacznie wolniejszy niż db_query, dlaczego miałbym go używać?

69

Informacje na ten temat można znaleźć na stronie http://drupal.org/node/1067802 .

Biorąc to wszystko pod uwagę, jakie sytuacje istnieją, w których mógłbym chcieć użyć db_select (), czy powinienem polegać wyłącznie na db_query?

7 performance database Chris Cohen
źródło

Odpowiedzi:

88

Istnieje 5 powodów, aby używać SelectQuery

  • Budujesz dynamiczne zapytania z różną liczbą warunków, połączeń, pól i tak dalej. Zobacz field_read_fields () jako przykład.

  • Chcesz używać tak zwanych ekstenderów . Przykładowymi przedłużaczami są PagerDefault (zastępuje pager_query () ) i TableSort (zastępuje tablesort_sql () ). Pozwalają one dodatkowo dodać funkcjonalność do SelectQuery. Zobacz także Jak tworzyć sortowalne tabele za pomocą pagera z danymi z niestandardowej tabeli? . Przykład: node_page_default () .

  • Chcesz zezwolić innym modułom na zmianę twoich zapytań. Następnie możesz dodać tak zwane tagi, a SelectQuery automatycznie wywoła odpowiedni haczyk alter dla tego tagu. W dużym stopniu polegam na tym w moim module Privatemsg (Zrobiliśmy to już w D6 z niestandardowym narzędziem do tworzenia zapytań).

  • Jeśli chcesz / musisz użyć systemu node_access, aby wyświetlić tylko węzły, użytkownik może to zobaczyć. Wystarczy dodać tag „node_access” do zapytania $. Zastępuje to db_rewrite_sql ().

  • SelectQuery ma kilka funkcji, dzięki którym kod działa tak samo we wszystkich obsługiwanych bazach danych. Na przykład istnieje SelectQuery :: orderRandom () . A jeśli masz warunek LIKE, -> warunek („pole”, wartość $, „LIKE”) upewni się, że porównanie zawsze nie uwzględnia wielkości liter. W D6 trzeba było użyć LOWER () do tego, co było znacznie wolniejsze. Ale AFAIK, nie ma teraz więcej niż tych dwóch.

Jeśli żaden z tych powodów nie ma zastosowania w konkretnym przypadku, użyj db_query ().

Berdir
źródło
1
Dodano piąty punkt, funkcje przenośności bazy danych, takie jak orderRandom () i LIKE bez rozróżniania wielkości liter.
Berdir
6
Jako szósty powód dodałbym kompatybilność między bazami danych. Na przykład zapytania Oracle mają składnię, która różni się pod pewnymi względami od MySQL, Postgres itp. O wiele łatwiej jest napisać kod, aby wygenerować poprawną składnię z db_select () niż w przypadku, gdy kod zapytania nie jest zbyt zgodny z Oracle jest zrzucany bezpośrednio do db_query ().
BrianV
9

Dokumentację odb_query() mówi:

Użyj tej funkcji do zapytań SELECT, jeśli jest to zwykły ciąg zapytania. Jeśli program wywołujący lub inne moduły muszą zmienić zapytanie, użyj zamiast tego db_select ().

marcvangend
źródło
Dzięki, ale to dość niespecyficzne. Pozostawia definicję „prostego ciągu zapytania” dość otwartą na interpretację. Jeśli wybieram spośród 4 tabel z 6 połączeniami, czy jest to nadal proste zapytanie, czy powinno to być zrobione za pomocą db_select ()?
Chris Cohen
3
Nie chodzi o „proste zapytanie”, ale o „prosty ciąg zapytania ” i prosty oznacza właściwie zakodowane, a nie dynamiczne. Zobacz moją odpowiedź po więcej szczegółów :)
Berdir
9

Zawsze używam db_select, ponieważ wolę czytelność, łatwość konserwacji i kompatybilność między bazami danych niż małe przyrosty wydajności. Co więcej, uważam, że liczby podane we wspomnianym numerze dają zły obraz ogólnej wydajności. Mówimy o 300 mikrosekundach różnicy w zapytaniu, które podczas zwracania więcej niż jednej kolumny często działa w zakresie wielu milisekund. I nie zdziwiłbym się, gdyby istniało jakieś jednorazowe obciążenie ogólne (ładowanie klasy), a zatem różnice dla żądania pełnego (strony) są znacznie mniejsze.

fietserwin
źródło
Różnica w wydajności nie jest taka prosta; zobacz Porównaj wydajność db_query i db_select . Ogólnie polecam db_query zamiast db_select, chyba że potrzebujesz jednej ze specjalnych funkcji wymienionych w odpowiedzi Berdira.
geerlingguy