count og limit

ad 1)
Der er ingen grund til at tælle samlige records og bruge limit medmindre at du ønsker dem grupperet. F.eks.

SELECT gruppe, count(*) AS antal FROM tabel
  GROUP BY gruppe
  WHERE ...
  LIMIT(0,10)

ad 2)
Nej du skal lave to forespørgsler

SELECT count(*) AS antal FROM tabel WHERE ...
SELECT * FROM tabel LIMIT(0,10) ORDER BY ... WHERE ...

ad 3)
den eneste løsning jeg ser er at bruge 2 forespørgsler.

Du kan optimere din
SELECT count(*) AS antal FROM tabel WHERE ...
hvis du har et entydigt index på f.eks. ID
SELECT count(id) AS antal FROM tabel WHERE ...

Jeg er ikke sikker på, det er bedre. Men du kan nøjes med een (stor)forespørgsel til databasen, hvis du først selecter alt det du skal have count på og derefter får din loop til at standse ved 10, når du skal bruge tabellen.
Eks. (ASP)
While (Not objRS.EOF) And T < 10
.....osv..
T = T + 1
objRS.MoveNext

Hvis det er performance, og en let måde at lave bladring på, så er det nemeiers løsning du skal bruge.

Du kan for at optimere det en anelse, nøjes med at lave SELECT COUNT på side 1 (limit 0,10), og gemme resultatet i sessionen eller lign.

--> Boris
Dette er ikke en særlig optimal løsning idet at alle informationer skal overføres fra MySQL serveren til arbejdsstationen der skal anvende informationen. Det gør ikke særligt meget når man bare har 200 records men hvis man har 200000 records har det en væsentlig betydning.

nemeier> optimalt betyder mindre når man kører ASP  ;-)

ups, sorry ..

--> flse
Det er ikke alle som har deres MySQL på samme maskine som deres web-server, i disse tilfælde vil 200000 records betyde en del, da disse skal flyttes over det fysiske net.

--> nemeier. Jeg skrev jo også, at jeg ikke var sikker på, det var bedre.
Det var en løsning, som betyder, at der kun bliver eet kald til databasen.
Om det er en god løsning afhænger f.eks. af, om det er 20 KB eller 20 MB data man henter hver gang!

nemier> det var ikke just det jeg mente  :-) 

uanset om MySQL kører på samme server som web-serveren, bør man aldrig selecte mere end man skal bruge.

-> principielt har i ganske ret.
Man skal selvfølgelig normalt ikke selecte mere end man skal bruge.
Men man skal på den anden side heller ikke lave to kald til basen, hvis man kan nøjes med et. Er det ikke det, spørgsmålet handler om?
Det kommer alt sammen an på, hvad det skal bruges til og om vi taler om et udtræk på  20 KB eller 200 MB.

boris> to kald til databasen koster ikke mere end den IO de genererer.

Desuden gik spørgsmålet egentlig på at benytte limit til bladring, og det kan ikke lade sig gøre samtidig finde antal mulig records ialt.

Hvis du laver det hele med en SQL sætning, og skal vise side 10, skal du først læse 90 records som du ikke skal bruge til noget, hvilket vil betyde minimum 90 overflødige IO ..
Desuden laver MySQL en forhåndslæsning af samtlige x antal records, uanset om du nøjes med at læse de 10 første.

--> flse
Hvis det er små datamængder, mener jeg ikke det er noget reelt problem. Det er i hvertfald ikke min erfaring.
Jeg ved ikke hvor meget det betyder at åbne og lukke to gange i stedet for en, men jeg går ud fra, at der sker en del i DBMS hver gang.

Hvis det er små datamængder på et site med få bruger, så er det ikke noget problem for MySQL.

Du løser dog stadig ikke opgaven med at læse/vise 10 records, hvilket man bedst gøre med limit, da man ellers skal kode sig ud af at skippe de x første records, hvilket er mere besværligt end at lave en select count til at starte med.

Hvis det ikke er de første 10 recors man vil se, men f.eks. nummer 53-62 er vi helt enige. Hvis det er de første 10 records er det ikke noget problem.
Limit er også bedst lige bortset fra at det i dette tilfælde åbenbart betyder to henvendelser til MySQL.
Hvad der er bedst-bedst  af de to bedste løsninger tør jeg ikke sige.

Syntes stadig du skulle læse spørgsmålet en gang til  :-)

"hvad er så den mest effektive måde at løse disse to opgaver på samme webside, uden at det går ud over performance ??  "

Nu er der argumenter for og imod foreløbig to løsninger.
Jeg tror ikke at hverken det ene eller det andet går ud over performance, med
mindre det er store datamængder det drejer sig om.
Lad peturkirke vælge eller måske kommer der en (endnu) smartere løsning?

boris> hvis du laver gennemløb af samtlige poster, så GÅR det ud over performance!  hvor meget afhænger selvfølgelig om det er 200 eller 200000 poster ..

undskyld jeg har været hjemme og sovet !

man skal aldrig gemme et recordset i session ! Det kan nemt gå ud over performance.
Jeg ved faktisk ikke, om min side vil få 10 brugere eller 100.000, men jeg vil lave den sådan, at den kan klare 100.000.
Jeg tror jeg vælger at lave 2 forespørgsler på hver eneste side. Først en som tæller samtlige fundne records, og siden en limit forespørgsel, der vælger f.eks. posterne 0-10 eller 210-220.
Hvad synes i om det ?

nej selvfølgelig skal samtlige fundne records gemmen i en session variabel, så slipper jeg for at lave den forespørgsel hver gang.