Potęga widoków – część II
by jmail on sie.11, 2009, under SQL
W pierwszej części pokazaliśmy sobie jeden widok. Wyniki nie były zaskakujące. Teraz jednak sobie utworzymy inny widoczek. W pierwszej części, robiliśmy tylko widok związany z tabelą użytkowników. Dzisiaj połączymy dwie tabele i zobaczymy czy takie połącznenie coś nam da.
Generalnie utworzenie widoku jest proste (z tabeli planet biorę tylko parę kolumn, tak samo jak z użytkowników):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | CREATE OR REPLACE VIEW up_v AS SELECT u.id ,u.username ,u.spy_tech ,u.military_tech ,u.defence_tech ,u.shield_tech ,p.id AS planet_id ,p.name ,p.metal ,p.crystal ,p.deuterium FROM prefix_users u INNER JOIN prefix_planets p ON p.id_owner = u.id WHERE u.onlinetime > unix_timestamp() - 7 * 24 * 60 * 60; |
W moim przypadku widok ma ok 3.000 rekordów. To już trochę daje. Teraz wykonujemy zapytanie (to samo którym tworzyliśmy widok) i jego czas wynosi 0.0626 i poprawiamy wszystko zapytaniem
1 | SELECT * FROM up_v |
Wynik 0.0525. To już jest konkretny zysk. I pomyśleć, ze to tylko na 3k rekordów. Co by było jakbyśmy całośc połączyli? Generalnie dałoby pewnie lepszy rezultat.
A teraz do brzego czas zacząć podsumowanie, które zakończymy w cześci trzeciej.
Widoki nawet już na małych ilościach danych będą się sprawdzać tak dobrze jak powinny, ale…. W części trzeciej przeindeksujemy sobie widok i będziemy jego aktualizować a przez to tabele pod spodem. Wtedy dopiero cała potęga rozwiązania ujawni.
Inna sprawa, że wybór porządnego serwera bazodanowego (PostgreSQL, MS SQL, Oracle) przynosi również pewne zyski. Ale porównanie systemów bazodanowych już niedługo.
Najważniejsze co należy podkreślić, to to, że pozostawanie w konwencji select, update insert delete i nic więcej nie sprawi, ze aplikacja zacznie pracować szybciej. Dużo lepszym rozwiązaniem jest pisanie procedur składowanych albo funkcji, które wykonują za nas całą brudną robotę. Do tego należy dodać bardzo ważną rzecz.
Napisanie funkcji, która wewnątrz ma UPDATE i wywołanie jej z poziomu PHP w postaci
1 | mysql_query("select nazwa_funkcji(/*tutaj paramtery*/)"); |
będzie dużo szybsze. UPDATE niestety w PHP idzie dużo wolniej niż SELECT, i do tego rozszerzenia do PHP nie oferuję wielu zapytań w jednej funkcji :/ Ale to już zupełnie inna historia.
