🚀 go-pugleaf

Użytkownik "John Doe" <spamujWYTNIJTO@op.pl> napisał w wiadomości 
news:3c23.00000089.46b6f5c2@newsgate.onet.pl...
>W jaki sposób zrobić limit wyników zwracanych z bazy XML ? Np 20 wyników na
> stronę i linki do wyboru strony.

Sposobow jest kilka.

Czysto xslt'owo: position(). Ale wtedy nie //x:oferta, tylko konkretna 
wzgledna sciezka.

Swoja droga skad moda na // ? Procesory potanialy?

Tyle, ze jest to srednio madre rozwiazanie. Bo jaki jest sens wyciagac 
zestaw danych dla 100 obiektow, jezeli wiesz, ze wyswietlisz 20?

Podaj namiar na dostawce procesorow, ktorych uzywasz...

Ja te rzeczy robie nieco inaczej. Bedzie nieco OT, ale co mi tam.

1. Wiesz czego szukasz, wiec pierwszym zapytaniem wyciagasz _tylko_ liste 
identyfikatorow spelniajacych warunki.
2. Zapamietujesz sobie te liste - na IIS'sie mozna to zrobic metoda 
brute-force, znaczy nadac nazwe taka jak SQL i zapamietac w zmiennej 
aplikacyjnej/sesyjnej.
3. Wyniki wyswietlasz przy pomocy drugiego zapytania, ktore prostym .split - 
.slice - .join wyciaga _dokladnie_ to czego potrzebujesz.
4. Przy "nastepnej" stronie sprawdzasz czy masz odpowiednia zmienna w swoim 
"cache". Jezeli jest: go to 3, jezeli nie: go to 2.

Pytanie: w sesji, czy w aplikacji? Prywatnie jestem wrogiem sesji (zwlaszcza 
w rozwiazaniach portalowo/informacyjno/referencyjnych). Wiekszosc zapytan 
uzytkownikow jest bolesnie powtarzalna (co mozna sprawdzic analizujac logi). 
Ergo: istotna czesc zapytan bedzie sie powtarzac, ergo: trzeba to 
wykorzystac.

I dlatego aplikacyjne.

Teraz jeszcze bardziej OT (dlatego cross-post).

Jezeli w serwisie dane sa czesciej czytane niz pisane _nie_ma_sensu_ meczyc 
bazy zadawaniem do niej w kolko tych samych zapytan. Statystycznie rzecz 
ujmujac o wiele czesciej zdarza sie sytuacja, ze ktos inny o _ten_sam_ 
zestaw danych od ich ostatniej aktualizacji zapytal, niz ze nikt tego nie 
zrobil.

I nalezy to bezwzglednie wykorzystac. Trzeba tylko pamietac, zeby przy 
aktualizacji danych pousuwac odpowiednia czesc przykeszowanych wynikow (przy 
pierwszym zapytaniu sie odtworza). Listy list rozwiazauja problem.

Zabawy troche wiecej, ale ile satysfakcji ;-)

Mozna pojsc dalej (ale to juz hardcore, wiec niekoniecznie za pierwszym 
razem) i przy _starcie_ serwisu wczytywac do aplikacji listy identyfikatorow 
"wyskakujacych" przy standardowych zapytaniach (najczesciej: lokalizacja i 
kategoria). A pozniej mnozyc tablice (byle nie wszystko przez wszystko, da 
sie o rzedy wielkosci wydajniej - na pl.comp.lang.javascript napisalem 
kiedys jak). I ewentualnie zapamietywac wyniki mnozen (ale tutaj jednak z 
kontrola liczby pamietanych wynikow).

Przy tym modelu trzeba pamietac o sporej liczbie drobiazgow. I moze cos o 
tym napisze, bo codeguru poprosilo mnie o artykul i byc moze to jest wlasnie 
temat.

-- --- -- --- -- --- 
sz. & Draco - byrnenski pies pasterski
http://szomiz.republika.pl/dod/draco/ 

Użytkownik "John Doe" <spamujWYTNIJTO@op.pl> napisał w wiadomości
news:3c23.00000089.46b6f5c2@newsgate.onet.pl...
>W jaki sposób zrobić limit wyników zwracanych z bazy XML ? Np 20 wyników na
> stronę i linki do wyboru strony.

Sposobow jest kilka.

Czysto xslt'owo: position(). Ale wtedy nie //x:oferta, tylko konkretna
wzgledna sciezka.

Swoja droga skad moda na // ? Procesory potanialy?

Tyle, ze jest to srednio madre rozwiazanie. Bo jaki jest sens wyciagac
zestaw danych dla 100 obiektow, jezeli wiesz, ze wyswietlisz 20?

Podaj namiar na dostawce procesorow, ktorych uzywasz...

Ja te rzeczy robie nieco inaczej. Bedzie nieco OT, ale co mi tam.

1. Wiesz czego szukasz, wiec pierwszym zapytaniem wyciagasz _tylko_ liste
identyfikatorow spelniajacych warunki.
2. Zapamietujesz sobie te liste - na IIS'sie mozna to zrobic metoda
brute-force, znaczy nadac nazwe taka jak SQL i zapamietac w zmiennej
aplikacyjnej/sesyjnej.
3. Wyniki wyswietlasz przy pomocy drugiego zapytania, ktore prostym .split -
.slice - .join wyciaga _dokladnie_ to czego potrzebujesz.
4. Przy "nastepnej" stronie sprawdzasz czy masz odpowiednia zmienna w swoim
"cache". Jezeli jest: go to 3, jezeli nie: go to 2.

Pytanie: w sesji, czy w aplikacji? Prywatnie jestem wrogiem sesji (zwlaszcza
w rozwiazaniach portalowo/informacyjno/referencyjnych). Wiekszosc zapytan
uzytkownikow jest bolesnie powtarzalna (co mozna sprawdzic analizujac logi).
Ergo: istotna czesc zapytan bedzie sie powtarzac, ergo: trzeba to
wykorzystac.

I dlatego aplikacyjne.

Teraz jeszcze bardziej OT (dlatego cross-post).

Jezeli w serwisie dane sa czesciej czytane niz pisane _nie_ma_sensu_ meczyc
bazy zadawaniem do niej w kolko tych samych zapytan. Statystycznie rzecz
ujmujac o wiele czesciej zdarza sie sytuacja, ze ktos inny o _ten_sam_
zestaw danych od ich ostatniej aktualizacji zapytal, niz ze nikt tego nie
zrobil.

I nalezy to bezwzglednie wykorzystac. Trzeba tylko pamietac, zeby przy
aktualizacji danych pousuwac odpowiednia czesc przykeszowanych wynikow (przy
pierwszym zapytaniu sie odtworza). Listy list rozwiazauja problem.

Zabawy troche wiecej, ale ile satysfakcji ;-)

Mozna pojsc dalej (ale to juz hardcore, wiec niekoniecznie za pierwszym
razem) i przy _starcie_ serwisu wczytywac do aplikacji listy identyfikatorow
"wyskakujacych" przy standardowych zapytaniach (najczesciej: lokalizacja i
kategoria). A pozniej mnozyc tablice (byle nie wszystko przez wszystko, da
sie o rzedy wielkosci wydajniej - na pl.comp.lang.javascript napisalem
kiedys jak). I ewentualnie zapamietywac wyniki mnozen (ale tutaj jednak z
kontrola liczby pamietanych wynikow).

Przy tym modelu trzeba pamietac o sporej liczbie drobiazgow. I moze cos o
tym napisze, bo codeguru poprosilo mnie o artykul i byc moze to jest wlasnie
temat.

-- --- -- --- -- --- 
sz. & Draco - byrnenski pies pasterski
http://szomiz.republika.pl/dod/draco/