Nie mam nic przeciwko, ale boję się, że wydajnośc będzie znikoma i nada się tylko do intranetowych projektów, gdzie w zasadzie takie cashowanie to ostatnia rzecz, jaką należy się przejmować. Może się mylę, ale cóż…:)
W każdym razie życzę powodzenia.

Problem z Twoim sterownikiem jest o tyle duży, że ciężko jest określić które zapytanie ma być buforowane a które nie. Niektóre z zapytań powtarzają się często, ale odwołują się do danych, które zmieniają się na bierząco, z kolei inne są wykonywane tak żadko, że mechanizm buforowania nie ma wpływu na szybkość działania całej aplikacji.

Problem z buforowaniem danych jest jeszcze większy gdy w grę wchodzi modyfikacja rekordów. Dopóki nie odpytasz bazy danych nie wiesz czy dane, które są w buforze są aktualne, a tylko na takich użytkownik powinien pracować prawda? :)

Problemów będzie zapewne wiecej, ale zawsze warto chociażby poszkicować sobie. :)

Pomysł niezły… ale jak to w życiu bywa mało realny niestety. Zazwyczaj pisząc aplikację masz jakieś pojęcie które zapytania mają wolno zmienne wyniki, a które raczej nie dadzą wa razy tego samego. Tym samym jakby z palca tworzysz cache i nie kombinujesz. Pytanie tez czy czas jaki poświęcisz na napisanie sterownika wróci się w rzeczywistych projektach.
pozdrawiam

Ja napisalem sobie jakis czas temu sterownik do db w ktorym do zapytan przekazywalem parametr, czy cachowac… Zalozenie bylo takie, ze tylko moja aplikacja www ma dostep do db. Inserty i Updaty, Delety automatycznie czyscily kazdy cache ktore wchodzily w relacje z ta tabela. Jednak, co oplaca sie cachowac? Nie wiele. NP: Statystyki. Wyciagniencie 10 newsow, jest tak szybkie, ze bardziej oplaca sie zadac pytanie do db niz pobrac cache z dysku.

Kolejna rzecz, kiedys z jaco rozmawialem o tym, doszlismy do wniosku, ze lepiej jest cachowac Cale fragmenty kodu strony - kod wynikowy - html. Mozesz dojsc wtedy do takiego momentu, ze strona jest po prostu odczytywana z dysku, 0 zapytan :) Ale musi byc tez dobra cachowanie, ktore bedize dbac o to, jakie dane sa aktualne.