odrazu przepraszam za temat ale nie da sie problemu opisac w temacie
Chcialem skonsultowac jak byscie rozwiazali w rubym taki problem, ktory u mnie np dosc czesto sie pojawia.
Zalozmy tabele w ktorej sa pola
data_od DATE
data_do DATE
kolor VARCHAR
Do tabeli oczywiscie odpowiedni model, duzej filozofii tu nie ma
no i teraz chcemy wygenerowac htmlowa tabelke w ktorej kolumny sa poszczegolnymi dniami , z tym ze dni dla ktorych istnieje w bazie informacja ze dany przedzial ma byc w jakims kolorze chcemy pokolorowac …
Jesli wiec tabelke generujemy zwykla tabelke z dniami (dla pewnego okresu niezaleznego od tego co jest w bazie) to robimy sobie zwykla petle po dniach DATA_OD.STEP(DATA_DO , 1 )
Bedac w srodku generujemy komorke no i musimy wiedziec jaki ma kolor ?
Jesli bedziemy za kazdym razem robili zapytanie do bazy to bedzie dosc nieladnie…
Narazie najprostsze rozwiazanie ktore znalazlem to wygenerowanie Hash w ktorej kluczami sa daty w odpowiednim formacie… najpierw laduje wiec wszystkie okresy z bazy i generuje ten Hash, a potem z niego czytam generujac tabelke…
No w kazdym razie ciekaw jestem jakie rozwiazania byscie zaproponowali ?
No jesli ta tabelka ma tylko 3 kolumny, to chyba nic bardzije prostego niz pobranie danych raz a potem przetwarzanie ich w rubym nie istnieje Ogolnie rails maja tendencje do nadmiernego zapytywania o cos baze, jesli uzywa sie np act_as_tree. Najlepiej pisac samemu implementacje drzewek, list itd niz korzystac z tego co oferuje rails w act_as bo sytuacje w ktorych jedno odswiezenie strony kosztuje 70 zapytan do bazy sa raczej nieporzadane
Nie widze rozsadniejszego rozwiazania problemu niz podane wyzej.
Co do nadmiernego pytania bazy to nie do konca jest tak.
Z zalozenia masz, ze dane nie sa pobierane do momentu kiedy sie do nich odwolujesz - to zachowanie mozesz oczywiscie banalnie prosto zmienic przez np :include dla joinow.
Twoj zarzut uwazam za bezpodstawny poniewaz sa tak naprawde tylko 2 podejscia albo obciazac baze zapytaniami albo obciazac zasoby serwera duzymi strukturami danych.
Masz wybor co chcesz robic a domyslne zachowanie jest dosc bezpieczne choc moze zarzucic baze duza iloscia zazwyczaj prostych zapytan z czym dzisiejsze bazy radza sobie swietnie.
Inaczej wygladalaby sytuacja gdzie ladowana jest cala struktura (np drzewa) i przy niewielkiej ilosci danych niesawiadomy programista uwazalby, ze wszystko jest ok… a w pewnym momencie aplikacja konsumowalaby ogromne ilosci pamieci.
IMHO nie ma sensu gdybać o tym co jest szybsze a co wolniejsze. U mnie w pracy spotykam osoby, które nawet zanim powstanie program juz z góry starają się coś “ulepszyć” albo “przyspieszyć”. Nie napiszą tego prosto, bo “PHP będzie musiał przejść po tej tablicy” A ile zajmie PHP przejście po tej tablicy?? 0.0034 sekundy ?? Kto to zauważy ?? W praktyce okazuje się, że spędzają na to “przyspieszanie” dużo czasu, który mogliby spędzić na tworzeniu reszty aplikacji.
Moja osobista rada jest taka:
Wymyśl rozwiązanie, które będzie przejrzyste i proste. Rails generuje kilka zapytań do bazy zamiast jednego ?? Hmmm, to co z tego ?? Strona wyświetla się i tak bardzo szybko. Nie staraj się już z góry tego przyspieszać. Jeśli twoja aplikacja rozrośnie się do ogromnych rozmiarów, takich że te kilka “SELECT”'ów zabije bazę wtedy pomyśl nad przyspieszeniem aplikacji.
Z doświadczenia jeszcze wspomnę, że wielu “chief systems architect” wymyśliło w mojej firmie rzeczy, które właśnie miały przyspieszyć działanie aplikacji a tak naprwdę spowolniły ogromnie pracę developerów przez zbytnie skomplikowanie, rozwlekłą konfigurację i “manual tweaking required”
Keep it simple - to chyba najlepsza rada.
Oczywiście, zdarzą się przypadki kiedy będziesz musiał to zagnieżdżone drzewko jakoś zoptymalizować, ale wtedy to będzie “bułka z masłem”, 1 przypadek na 100.
No wlasnie, sprawa jest taka ze jesli chodzi o Hash table to nie do konca wiem jak dzilaja tam od srodka.
Bo rozwiazanie z hashami moze w wielu miejscach bardzo bardzo ulatwic sprawe, tylko chcialbym zrozumiec jak dziala…
jesli chodzi o ten przypadek to wyswietlam zazwyczaj 90 dni (90 kolumn w tabelce)
zapytanie ktore pobiera mi okresy ktore trzeba ‘pokolorowac’ zalozmy ze zwraca jakies 3-4 rekordy, wiec robie sobie petle pokolei po kazdym dniu
data_od.step(data_do,1)
i wypelniam hash
tabl[data jako ‘DD-MM-YYYY’] = kolor
potem wiec prosta sprawa jest sprawdzic jaki kolor jest danego dnia.
W tej chwili nie czuje obciazenia, ale tez nie analizuje go w zaden sposob.
Nie chcialbym tez zostawiac takich bykow ktore beda potem bardzo niewydajne - jak np robienie select dla kazdego dnia…
Tak wiec zostawiam narazie hashe i pytanie kieruje w ta strone - czy ktos wnikal mocno w wydajnosc hashy ?
Ja mam podbne zdanie jak hosiawak - Nie szukac problemu gdy go jeszcze nie ma. Co oczywiscie nie zwalnia od myslenia Poszczegolne fragmenty projektu ulegaja z czasem przeprojektowaniu z innych wzgledow i “rzekomy” problem moze wrecz samoistnie zniknac.
Zakladam, ze okresy nie moga na siebie zachodzic?
Mozesz np. wzbogacic Date (czy DateTime, co tam uzywasz) o cell_color property. Normalniej byloby inheritance ale to Ruby
class Date
attr_accessor :cell_color
end
# w modelu:
def self.days_for_period(date_from, date_to)
all_days # stworzenie tablicy obiektow Date zakresu + ustawienie default cell_color
scheduled_days # kalkulacja "kolorowych dni" na podst rekordow w bazie
# (tak jak w przyp. hashu ale ustawianie koloru dla Date i
# wstawienie obiektu w tablice
all_days | scheduled_days # union - polaczenie i usuniecie
# duplikatow. tablica jest juz posortowana.
end
Powyzsze raczej na pewno nie jest wydajniejsze od hasha! … Ale ja chyba tak bym sie do tego zabral (tylko jednak zrobil inheritance: ScheduleCell < Date czy cos w tym stylu).
Hash jest mysle OK, bo jesli dobrze zrozumialem to select z where … beetween bylby dla kazdego dnia (te przykladowe 90 kolumn) i caly obiekt (nie wiem jakie tam jeszcze sa properties, chyba ze find_by_sql) tylko po to aby wyciagnac kolor chyba nie ma sensu.
To tylko kolor (string?) co innego z duzymi tablicami bajtowymi.
Wydaje mi sie, ze kolega hasiowak czytal Getting Real (swoja droga swietna ksiazka).
W pelni zgadzam sie z tym podejsciem.
Programowac i projektowac swiadomie i ale nie szukac problemow - szczegolnie wydajnosciowych - gdy ich jeszcze nie ma (liczyc na to, ze sie pojawia bo serwis/aplikacja stana sie popularne).
Ogolnie rails maja tendencje do nadmiernego zapytywania o cos baze, jesli uzywa sie np act_as_tree. Najlepiej pisac samemu implementacje drzewek, list itd niz korzystac z tego co oferuje rails w act_as bo sytuacje w ktorych jedno odswiezenie strony kosztuje 70 zapytan do bazy sa raczej nieporzadane 