Wielki JOIN czy 6*SELECT, a wydajność ? Opcje

[jastu]

Witam,
stoję przed dylematem :

- napisać kwerendę która stworzy widok z 6 tabel i z tego widoku jednym zapytaniem pobierać dane ?
- napisać 6 mniejszych prostych selectów ?

Od czego może zależeć wybór rozwiazania i na co zwrócić uwagę ?

Pozdrawiam

[czachor]

Najlepiej chyba kilka selectów. Miałem podobny problem (tu), robiłem UNION, ale kombinowałem też z JOIN, optymalizacyjnie wyglądało to fatalnie, zapytanie wykonywało się nawet po 20 sekund przy stosunkowo niedużych tabelach. Teraz mam select'y i jest o wiele szybciej. To taka moja subiektywna opinia. Jakby udało Ci sie coś sensownego stworzyć, to byłbym też wdzięczny Ci za pokazanie sposobu.

[Cezar708]

należy pamiętać, że stworzenie widoku znacznie przyspiesza pobieranie danych, szczególnie może mieć to znaczenie przy większej liczbie danych. Ja na Twoim miejscu postawiłbym na utworzenie widoku. Kilka selectów to po pierwsze więcej zapytań (a operacje I/O jaką jest komunikacja z bazą danych zawsze są i będą wąskim gardłem), a po drugie więcej męczenia się z kodem php (co wydłuża czas jego działania i powoduje, że jest bardziej skomplikowany i nieczytelny)

EDIT

--- ale fakt faktem najlepiej jest sprawdzić to empirycznie, bo dla różnych struktur, ilości danych wyniki mogą być różne i w niektórych przypadkach więcej selectów może dać lepszy wynik

Ten post edytował Cezar708 7.01.2008, 14:25:08

[specialplan]

Z mojego doswiadczenia wynika, ze lepiej jest stworzyc widok i iterowac po powstalej tablicy wynikow. Ale jak juz "doedytowal" Cezar - sprawdz empirycznie co dla Ciebie bedzie lepsze. PZdr

[Jarod]

@Cezar708: Ale czy przypadkiem nie jest tak, że odwołując się do widoku, baza i tak wykonuje to dłuższe zapytanie?

[TomaySOFT]

Niezależnie od tego, czy stworzysz widok, czy ileś tam podselectów wydajność będzie zależała od prawidłowego poindeksowania odpytywanych tabel. Mam doświadczenie z tabelami liczącymi sobie do kilkuset tysięcy rekordów, które zawierają bardziej lub mniej złożone dane (typu integer czy nawet varchar) i zawsze wychodzi na to, że bez indeksów zapytanie będzie trwało do x razy dłużej (przy x dążącym do nieskończoności) niż wtedy, gdy dobrze założysz indeksy...
Przykład:
Forum z tabelą userów (autoincrement, id_usera, login) i tabelą postów (autoincrement, id_usera, id_tematu, treść), a zapytanie będzie dotyczyło choćby ilości postów usera po jego loginie....
Jesli w tabeli postów i userów nie poindeksujesz pól z id_usera to... zapytanie będzie skrajnie niewydajne - z indeksami czas wykonania będzie... ludzki.
Jeśli chcesz wykorzystać joina lub 6 niezależnych zapytań, to różnica w czasie wykonania zaczyna być nieoceniona.
Musisz stosować zasadę: jeśli gdzieś zechcesz się o tabelę zapytać stosując klauzulę where wg jakiegoś pola, to musisz je poindeksować - nawet kosztem (podobno) ciut wolniejszych insertów do tych tabel - to się po prostu zwróci z nawiązką przy bardziej złożonych kwerendach.
A - jeśli jeszcze masz wątpliwości w tej kwestii - ew. przyszłe zapytania z joinem zadaj jako parametr do funkcji explain, a w wyniku dowiesz się, czy baza skorzysta z jakichkolwiek indeksów ("possible index"), czy też będzie po prostu przeszukiwała tabele rekord po rekordzie...

Pozdro