To naprawdę zależy, miałem sytuacje, w których poprawiłem niektóre zapytania za pomocą podzapytań.
Czynniki, o których wiem, to:
- czy podzapytanie używa pól z zapytania zewnętrznego do porównania, czy nie (skorelowane czy nie)
- jeśli relacja między zapytaniem zewnętrznym a zapytaniem podrzędnym jest objęta indeksami
- jeśli nie ma użytecznych indeksów w złączach, a podzapytanie nie jest skorelowane i zwraca mały wynik, użycie go może być szybsze
- Zetknąłem się również z sytuacjami, w których przekształcenie zapytania używającego porządku by w zapytanie, które go nie używa, a następnie przekształcenie go w proste podzapytanie i sortowanie, które poprawia wydajność w mysql
Tak czy inaczej, zawsze dobrze jest testować różne warianty (proszę z SQL_NO_CACHE), a przekształcanie skorelowanych zapytań w złączenia jest dobrą praktyką.
Posunąłbym się nawet do tego, że nazwałbym to bardzo pożyteczną praktyką.
Możliwe, że jeśli skorelowane zapytania są pierwszymi, które przychodzą ci na myśl, że nie myślisz głównie w kategoriach operacji na zbiorach, ale przede wszystkim w kategoriach operacji proceduralnych, a kiedy masz do czynienia z relacyjnymi bazami danych, bardzo przydatne jest pełne zaadoptowanie zbioru perspektywę na model danych i przekształcenia na nim.
EDYCJA:Proceduralne a relacyjne
Myślenie w kategoriach operacji na zbiorach a proceduralnych sprowadza się do równoważności w niektórych wyrażeniach algebry zbiorów, na przykład zaznaczanie na sumie jest równoznaczne z sumą selekcji. Nie ma między nimi żadnej różnicy.
Ale kiedy porównasz te dwie procedury, takie jak zastosowanie kryteriów wyboru do każdego elementu unii za pomocą opcji „stwórz unię”, a następnie zastosuj selekcję, obie są wyraźnie różnymi procedurami, które mogą mają bardzo różne właściwości (na przykład wykorzystanie procesora, we/wy, pamięci).
Ideą relacyjnych baz danych jest to, że nie próbujesz opisać, jak uzyskać wynik (procedurę), ale tylko to, czego chcesz, a system zarządzania bazą danych wybierze najlepszą ścieżkę (procedurę) do spełnienia Twojego żądania. Dlatego SQL nazywa się językiem czwartej generacji (4GL) .
Jedną ze sztuczek, które mogą ci w tym pomóc, jest przypomnienie sobie, że krotki nie mają własnego porządku (elementy zbioru są nieuporządkowane). Innym jest uświadomienie sobie, że algebra relacyjna jest dość wszechstronna i umożliwia tłumaczenie żądań (wymagań) bezpośrednio do SQL (jeśli semantyka Twój model dobrze reprezentuje przestrzeń problemu lub innymi słowy, jeśli znaczenie przypisane do nazw twoich tabel i relacji jest dobrze zrobione, lub innymi słowy, jeśli twoja baza danych jest dobrze zaprojektowana).
Dlatego nie musisz myśleć jak, tylko co.
W twoim przypadku była to po prostu preferencja nad skorelowanymi zapytaniami, więc może być tak, że nie mówię ci nic nowego, ale podkreśliłeś ten punkt, stąd komentarz.
Myślę, że gdybyś był całkowicie zadowolony ze wszystkich reguł, które przekształcają zapytania z jednej formy w drugą (zasady takie jak dystrybucyjność), że nie wolisz skorelowanych podzapytań (że wszystkie formy będą traktowane jako równe).
(Uwaga:powyżej omówiono podstawy teoretyczne, ważne dla projektowania baz danych; praktycznie powyższe koncepcje odbiegają od siebie - nie wszystkie równoważne przepisania zapytania są koniecznie wykonywane tak szybko, klastrowane klucze podstawowe powodują, że tabele mają porządek dziedziczenia na dysku itp., ale te odchylenia są tylko odchyleniami; fakt, że nie wszystkie równoważne zapytania są wykonywane tak szybko, jest niedoskonałością samego DBMS, a nie koncepcji, które za nim stoją)
