|
Prikaz tabele sa mnostvom slogova
Nesto razmisljam kako bih mogao da resim jedan problem. Opisacu ga ovde u opstem obliku:
web dokument se generise tako sto se pokrene jedna kompleksna funicija koja vuce podatke iz baze, koji ne samo sto je kompleksna i ima mnogobrada podataka pre prikaza nego je rezultat ogroman broj slogova. Tako dobijene podatke treba prikazati. Normalno, neophodno je omoguciti korsiniku da podatke vidi po stranama koje su ogranicene na prikaz razumnog broja slogova. Mejutim, neekonomicno je da se za prikaz svake strane ponovo poizva funkciaj koja izvlaci podatke iz baze, jer trosi znacajne resurse. Resenje koje se namece je da se prilikom prvog otvaranja dokumenta izgenerise tabela sa podacima ali kao neka privremena tabela koja nece biti brisana nakon prikaza dokumenta, a da se za stvarni prikaz koristi jednostavan upit koji iz te privremene tabele izvlaci samo one slogove koji su potrebni za prikaz izabrane strane. Preko sesije bi se moglo obezbediti da tu privremenu tabelu visi samo korsinik koji je inicirao prikaz dokumenta. Tu treba resiti neke stvari kao sto je recimo, kako znati kada tu privremenu tabelu treba obrisati a verovatno i neka druga koja mi nepadaju na pamet. Da li je neko resavao ovakav problem? |
Da, mi imamo nešto slično u našoj aplikaciji. To se u mom selu inače zove keširanje. ;)
Imamo globalni keš, ne na nivou sesije. Ako se podaci razlikuju u zavisnosti od korisnika koji ih je zahtevao, dodamo još userid u keš ključ. Za keš koristimo gotovu MS-ovu helper klasu (tipa heštabele), a same kolekcije u XML-u (u pitanju je stablasta struktura, za razliku od tvog slučaja gde je u pitanju ravna tabela). Keš je ograničen sopstvenim kapacitetom i helper se sam stara o izbacivanju najstarijih elemenata. Imamo prilično komplikovan sistem "ručne" invalidacije keša, kad se promeni neki podatak koji se nalazi u nekoj keširanoj kolekciji. Plus veb servis za invalidaciju sa drugih servera iz veb farme. Eh, da, zašto izvlačiš celu tabelu, a ne samo deo koji je korisnik tražio? |
Nisam naisao na slican problem, ali mi pada na pamet nesto slicno kao i tebi, recimo da napravis tabelu cached_data (koja je obicna tabela), sa dodatnim poljem koje sadrzi id ili ime korisnika koji gleda podatke, i jos jednu tabelu, npr. cached_data_stamps, sa id/imenom korisnika i vremenom nastanka pomenute kopije podataka. Tako mozes da pristupas podacima do mile volje, a znaces ko ih je kreirao i kada, pa ces moci da ih uklonis kada se vise ne koriste (verovatno bi ti odgovarao isti interval koji koristis za istek sesije, ili recimo period neaktivnosti korisnika veci od X minuta...). Posto se paginacija uglavnom implementira dodavanjem ekstra parametra URL-u (npr. ?page=), primetices da je jedina stranica koja nema ?page= parametar zapravo samo pocetna stranica, ona koju dobijes klikom na link koji vodi ka stranici, pa tu okolnost mozes iskoristiti kao priliku za generisanje podataka, a sve ostale zahteve za ?page samo vadis podatke iz kesha.
Ne znam da li bi ti ovo resilo problem, mada meni deluje ok (struktura same tabele ne bi morala da ima primarni key, samo index na polju user id/name, pored kljuceva koje tvoji podaci zahtevaju). Jedini problem bio bi ako znas da ce te podatke (verujem da su u pitanju neki glomazni izvestaji) gledati vise ljudi istovremeno, i to dosta cesto, sto bi, zavisno od broja zapisa u krajnjem rezultatu, moglo da prouzrokuje ubrzan rast baze ili povecan load. [edit]Preduhitren sam :)[/edit] |
Mora da se uradi cela tabela zato sto recimo treba da se obezbedi suma po nekim kolonama za celu tabelu ( a ne samo za stranu kaj se prikazuje), tako da sam zakljucio da je najbolej jednom odraditi sve obrade kojima sse dobijau podaci a posle samo priakzivati.
Ovo niej bas klasican kes, jer se generise za svaki dokument i za svakog korisnika ponaosob. Proto podatke treba izgenerisati sbaki put kada korsink zeli dapogleda dokument, samo treba napraviti medjukes koliko da se zaprikaz pojedinih strana ne generise sveiznova. zexxtra, otprilike se moaj ideja poklapa a ovom tvojom, podatke u privremenoj tabeli bih vezivao za mehanizam sesije te bih tako resio pitanje "kada treba obrisati privremenu tabelu - prosto, kada istekne sesija, ni za tom tabelom vise nema potrebe. Da, pade mi na pamet jos jedna problem: sta ako korisnik otvori izti izvestaj u dva prozora, sa ralicitim paametrima. Morao bih da svakoj privremenoj tabeli dam neki ID pa da ga prosledjujem kroz strane (u linkovima), kako bi apliakcija znala koju tabelu treba da prikazuje. Olaksavajuc aokolnost je da nece ove izvestaje gledati istvoremeno veliki broj ljudi tako da nece bas biti preteranog zauzeca prostora, ali cak i da je tako, tu ne mogu nista, jer svaki korsinik moze da unese razlicite parametre izvestaja i tako gleda razlicite podatke. Najnepovoljnije u celoj stvari je to sto ne mogu da se oslonim ni na jedan postojeci mehanizam, jer ih nemam, sve moram da napravim od nule. Ali, princip je isti, sve su smo nijanse u realizaciji :) |
U svakom slucaju za ovakve stvari mogu lepo da se koriste temp tabele, narocito ako ces umesto krajnjeg rezultata da pamtis neki zahtevni medjurezultat (tipa tih nekih suma recimo) pa da onda izvlacis sta ti treba odatle.
Ako ces da samo zapamtis gotove rezultate i da ih redom prikazujes (ne treba ti search, sortiranje i sl funkcije baze) onda je mozda bolje da guras te podatke u neki fajl, a da pamtis offset do kog se stiglo u sesiju. I onda samo uradis seek do linije koja je na redu i izprintas sledecih X linija i to je to... |
Vidis, to ti nije losa ideja da napravim dodatnu pretragu i soritranje po gotovim podacima, kad ih vec drzim u tabeli... hm..ovo ce jos da ispadne i da ima znacajnu dobit u funkcionalnosti... da sam znao unapred na sta ce sve ovo da ispadne, ne bih se ni upustao :)
Ne bih bas korsitio unapred generisan sadrzaj za prikaz, jer bih omogucio korsiniku da menja nacin prikaza, recimo da moze da menja broj slogova koji ce da se prikazuje na jednoj strani, a zasto ne i da moze da naknadno sortira kako mu odgovara... |
Citat:
|
M anije ovo kod koji mogu da upotrebim na drugom mestu. To je sve tako specificno i vezano za platformu da prsoto nije upotrebljivo drugacije. Koristilo mi je jer sam usput mnogo naucio, a kako i ne bi kad sam napravio "PHP umesto PHP-a".
Na pocetku je to izgledalo kao mali skriptic i gotovo a ispade celo razvojno okruzenje. :) |
| Vreme je GMT +2. Trenutno vreme je 16:31. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.