Mam pewien dylemat.
Postanowiłem napisać forum jako dodatek do pewnego CMSa, do którego jeszcze nie ma forum :-)
Upraszczajac - mam tabele uzytkownikow, for, grup użytkowników, tabele z dostepami (id, nazwa, czytanie, pisanie, etc) oraz tabele z mapami:
a) forumAccess - forumId -> groupId -> AccessId
groupMap - userId -> groupId.
Zalozenie - każdy użytkownik może być przypisany do wielu grup. Czyli mając 1 usera, przypisanego do 2 grup, mając 100 for, dostaje 200 rekordów. Przy 100 uzytkownikach osiągnąć mogę już liczbę 20 000 rekordów.
Oczywiście pobierajac listę for, pobieram tylko 100 rekordów z tych 20 000 możliwych (maksymalne wartości dla danego użytkownika w danej chwili).
Postanowiłem, ze posile się widokami. I tu moje pytanie - czy to dobre podejście do mojego zagadnienia?
Mniej wiecej to będzie wyglądało tak:
1. Zapytanie wyciagajace listę for.
2. Na zapytaniu mam Joina na widoku, który pobiera mi maksymalne wartości z drugiego widoku. Pobiera ono tyle rekordów ile jest for.
3. W tym drugim widoku planuje jeszcze dodać jeden Select poprzez Union All.
Czy to aby nie zapcha mi bazy czasem wykonania zapytania?
Myślałem, aby stworzyć tabele z tymi wynikami, które otrzymuje poprzez widoki i dodawanie/edycje/usuwanie oprogramowac Triggerami. Ale czy to byłoby słuszne? Tabela po czasie miałaby masę rekordów, a ja wybieram dla konkretnego Usera u Forum.
Jak z indeksami w widokach? Dzialaja? I czy działają jeśli zrobię Union All w widoku?
Czy jak mam w zapytaniu czasem Where/Join na UserId, czasem na ForumId, a czasem na oba pola, to powinienem zastosować indeksy pojedyncze czy złożone, a może jedne i drugie?
Z góry dzięki za odpowiedzi na nurtujace mnie pytania i wątpliwości.
"Programistą" jestem hobbystycznie - jakąś tam wiedzę mam, ale takiego życiowego doświadczenia brak u mnie :)
Ja co prawda używam PostgreSQL, ale myślę, że w kwestii podstawowych zapytań nie powinno być znaczących różnic pomiędzy nim, a MySQL.
Czy to aby nie zapcha mi bazy czasem wykonania zapytania?
Jak z indeksami w widokach? Dzialaja?
Przy projekcie, w którym pracuję, mam widoki joinujące 4-5 tabel, każdy z tych widoków ma kilkanaście-kilkadziesiąc milionów linii i zapytania śmigają w 5-10 ms. Podstawa to rozsądna konstrukcja widoku (brak zagnieżdżonych zapytań, pętli/warunków itp. + indeksy w rozsądnych miejscach.
Myślałem, aby stworzyć tabele z tymi wynikami, które otrzymuje poprzez widoki i dodawanie/edycje/usuwanie oprogramowac Triggerami. Ale czy to byłoby słuszne? Tabela po czasie miałaby masę rekordów, a ja wybieram dla konkretnego Usera u Forum.
Ten pomysł funkcjonuje jako "materialized view". Sam używałem raz - przyrost wydajności symboliczny, a utrzymanie bywa uciążliwe, jesli projekt szybko rośnie. Dla mnie to raczej zły pomysł - jeśli już, to do trzymania danych archiwalnych i odciążenia tabel z danymi "bieżącymi". Czasami sprawdza się "cache'owanie" jakichś danych w miejscu, gdzie są potrzebne (denormalizacja), ale to czy to dobry pomysł zależy od konkretnego problemu - ciężko o uniwersalną radę. Ja np. robiąc drzewo kategorii w sklepie, trzymałem w osobnej tabeli dla każdej kategorii wszystkich jej potomków (para: kategoria - potomek), przez co unikałem dużego obciążenia szeregiem zapytań pobierających wszystkie liście danego węzła.
Czy jak mam w zapytaniu czasem Where/Join na UserId, czasem na ForumId, a czasem na oba pola, to powinienem zastosować indeksy pojedyncze czy złożone, a może jedne i drugie?
To zależy - indeks przyspiesza wyszukiwanie, ale spowalnia zapisy. Grunt to pamiętać, że jeśli masz indeks na kolumnach "A, B", to w przypadku zapytania używającego "A" także zostanie on wykorzystany (zakładam, że mowa o indeksie typu btree dla Postgresa - czyli drzewo, a nie np. hashtable). Natomiast przy odwołaniu do "B" - już nie.
Regis, a powiedz mi proszę - jak wygląda sprawa zagnieżdżonych widoków?
Chodzi o to, że mam widok z jednym Selectem.
Drugi - tutaj troszkę bardziej skomplikowany Select (3 Joiny) ;)
I trzeci widok - który robi Union All na tych dwóch selectach.
I do tego trzeciego widoku się odwołuję później w zapytaniu.
Trochę skomplikowane i to mnie trapi - czy to podoła :D
