spørgsmål vedr. struktur i paging funktion

Som jeg læser det ...

Så henter du 25 poster fra databasen ... og så begynder du at filtrere på det, korrekt forstået ?

Hvis du kan svare ja til overstående, så vil jeg mener ud gør du forkert ... hvorfor ik' sortere dem fra i dit SQL kald ?

mvh

Kan du ikke hente alle poster på en gang? Eller er der for mange?

til buzzzz - jeg vil jo give brugeren mulighed for at få vist alle tøjmærker eller fravælge nogle af dem - derfor er jeg ved første kald nødt til at vide hvor mange tøjmærker det samlede søgeresultat vil indeholde - og ikke kun på de første 25 poster

Så er du jo som Janus skriver, nød til at hente alle poster, og derefter sortere dit resultat client side.

nickbuus -> Du kan også lave en count og sende den med i dit ajax response, det er sådan det normalt gøres hvis man ikke vil hente alt ned clientside.

janus - men jeg skal jo bruge en liste med id over de tøjmærker som findes i den samlede søgning - det kan vel ikke laves ved at returnere et count?

Nu ved jeg ikke lige hvordan du har skruet dit ajax kald sammen, men hvis vi nu siger du bruger JSON til response, så vil du have et container object hvor den ene property fortæller total count og en anden til en collection af de 25 mærker.

Dvs. 2 kald imod DB'en, et som henter count og et andet som henter mærkerne. Typisk vil de 2 kald ske på serveren, sådan at ajax requesten kalder en service som udfører de nødvendige sql-kald.

Når du ændrer på søgekriterierne er du også nød til at forespørge igen for at have det korrekte grundlag for din paginering. Det må være svaret i sin basisform.

Hvis du så vil optimere på dette, kan du benytte en cache til dine data, som du søger i. En yderligere optimering (af hukommelsesforbruget) kunne så være, at implementere et indeks i hukommelsen, som kun indeholder de oplysninger der bruges til at filtrere data med, f.eks. id og tøjmærke (som formegentlig kun er en delmængde af de data dit udtrøk består af). Så kunne du foretage et opslag i dette indeks for at se hvormange og hvilke rækker der skal udtrækkes til det ønskede kriterium. Begge varianter kræver at du cacher alle rækker. Med alle data cached, kan du nøjes med at slå op i databasen én gang og med den sidste, skal der foretages et opslag i databasen hver gang en side hentes, men altså kun for de rækker der skal vises på den aktuelle side i dit resultat...

Du kan yderligere rykke indekset ud på klienten, så du kan ændre pagineringen på klienten. Du kan desuden kombinere det med et predictive fetch-mønster der først henter de data der skal vises lige her og nu og så i baggrunden henter det næste sæt data (f.eks. den næste side, hvis det er det der er mest sandsynligt at brugeren vil se) og cacher disse rækker på klienten så de er klar til visning når de bliver nødvendige at vise.

Der findes forskellige måder at optimere systmer på, men det er som regel et spørgsmål om cost/benefit, hvilken løsning man har råd til at implementere... :-)