---

Hej gruppe!
Jeg har set på mange sider at man kan bldre igennem f.eks brugerne på side.
Så står der
?page=2 på de næste. Hvordan gør man det. det skal tage fra en mysql
database? Der skal være 20 på hver side!

--
MVH
Michael/Storkie
www.storkie.1go.dk

---

Michael Korsgaard wrote:
> side. Så står der
> ?page=2 på de næste. Hvordan gør man det. det skal tage fra en mysql
> database? Der skal være 20 på hver side!

Du hopper hen over de 20 første...

Spøg til side - du sorterer normalt en forespørgsel efter nogle felter. Hvis
du sorterer efter noget unikt, f.eks. en postnummer liste, der er sorteret
efter postnummer, så kan du lægge mærke til, hvilket postnummer side 1
nåede til, og i linket til side 2 angive dette.

Så hvis første side indeholder postnumre op til 2000, så kan du i side to
lave en forespørgsel, som henter de første 20 postnumre, der er større end
2000.

Lars.

--
Freelance programmør
Programmering mod timebetaling

---

Det blev vist lige misforstået!
F.eks når du søger på google viser den de første måske 10 resultar så kan
man klikke på en næste knap hvis der er flere!
"Lars Dybdahl" <lars@dybdahl.net> skrev i en meddelelse
news:3ec2492b$0$97184$edfadb0f@dread12.news.tele.dk...
> Michael Korsgaard wrote:
> > side. Så står der
> > ?page=2 på de næste. Hvordan gør man det. det skal tage fra en mysql
> > database? Der skal være 20 på hver side!
>
> Du hopper hen over de 20 første...
>
> Spøg til side - du sorterer normalt en forespørgsel efter nogle felter.
Hvis
> du sorterer efter noget unikt, f.eks. en postnummer liste, der er sorteret
> efter postnummer, så kan du lægge mærke til, hvilket postnummer side 1
> nåede til, og i linket til side 2 angive dette.
>
> Så hvis første side indeholder postnumre op til 2000, så kan du i side to
> lave en forespørgsel, som henter de første 20 postnumre, der er større end
> 2000.
>
> Lars.
>
> --
> Freelance programmør
> Programmering mod timebetaling

---

Michael Korsgaard wrote:
> F.eks når du søger på google viser den de første måske 10 resultar så kan
> man klikke på en næste knap hvis der er flere!

Ja netop.

> Det blev vist lige misforstået!

Nej. Jeg omtaler netop en funktionalitet som f.eks. google's søgeresultater.

Lars.

--
Freelance programmør
Programmering mod timebetaling

---

Lars Dybdahl wrote:

> Spøg til side - du sorterer normalt en forespørgsel efter nogle
> felter. Hvis du sorterer efter noget unikt, f.eks. en postnummer
> liste, der er sorteret efter postnummer, så kan du lægge mærke til,
> hvilket postnummer side 1 nåede til, og i linket til side 2 angive
> dette.

Det var da en underlig måde at lave det på?

> Så hvis første side indeholder postnumre op til 2000, så kan du i
> side to lave en forespørgsel, som henter de første 20 postnumre, der
> er større end 2000.

og hvis det er navne på en masse mennesker, og den deler ved Christian, som
der er 2 af, hvad så?

Kodeordet er offset og limit

SELECT name FROM kartotek LIMIT 40, 20; # viser 41-60

--
Take Care
Kim Emax - Freelance programmør
http://www.emax.dk - http://www.ayianapa.dk
Køb din vin online på http://www.gmvin.dk,
Danmarks måske mest avancerede VinWebShop

---

"Kim Emax" <newsgroup@remove-emax.dk> wrote in message
news:k1twa.61001$y3.4441241@news010.worldonline.dk...
> Lars Dybdahl wrote:
>
> > Spøg til side - du sorterer normalt en forespørgsel efter nogle
> > felter. Hvis du sorterer efter noget unikt, f.eks. en postnummer
> > liste, der er sorteret efter postnummer, så kan du lægge mærke til,
> > hvilket postnummer side 1 nåede til, og i linket til side 2 angive
> > dette.
>
> Det var da en underlig måde at lave det på?

Enig - Det lyder helt i skoven.


> Kodeordet er offset og limit

Præcis.

Mvh
Jimmy

---

Kim Emax wrote:
> Det var da en underlig måde at lave det på?

Prøv at tænke på performance... hvis du kan lave et enkelt indeks opslag og
så allerede levere den første html kode til visning i brugerens browser, så
er det væsentligt hurtigere end hvis den først skal hoppe n gange 20
records frem (eller hvor mange der nu er på hver side).

Man kan simpelthen have flere besøgende og får et hurtigere website på den
måde.

> og hvis det er navne på en masse mennesker, og den deler ved Christian,
> som der er 2 af, hvad så?

Som jeg skrev, virker metoden kun, når du sorterer på unikke index, så hvis
du sorterer på navne på mennesker kan metoden ikke anvendes. Så skal du
bruge mere avancerede metoder, som f.eks. at hoppe et antal records frem
(evt. lade sql serveren gøre det vha. LIMIT).

Man kan også kombinere de to metoder, hvis man både vil have performance og
vil have mulighed for f.eks. direkte opslag på en bestemt side.

Forskellen mellem de to metoder er ikke så stor, hvis serveren er ubelastet
og mysql kører på samme maskine som webserveren, men hvis systemet er
belastet, så er indeksopslag klart at foretrække frem for sekventiel
gennembladring af records.

Lars.

--
Freelance programmør
Programmering mod timebetaling

---

Lars Dybdahl wrote:
> Prøv at tænke på performance... hvis du kan lave et enkelt indeks opslag og
> så allerede levere den første html kode til visning i brugerens browser, så
> er det væsentligt hurtigere end hvis den først skal hoppe n gange 20
> records frem (eller hvor mange der nu er på hver side).
>
> Man kan simpelthen have flere besøgende og får et hurtigere website på den
> måde.

Hvad er det for noget vås?
Det passer jo ikke!? Jeg vil gerne se beviser for dette... for så kan du
ikke lave dine queries ordentlig...

>>og hvis det er navne på en masse mennesker, og den deler ved Christian,
>>som der er 2 af, hvad så?
>
> Som jeg skrev, virker metoden kun, når du sorterer på unikke index, så hvis
> du sorterer på navne på mennesker kan metoden ikke anvendes. Så skal du
> bruge mere avancerede metoder, som f.eks. at hoppe et antal records frem
> (evt. lade sql serveren gøre det vha. LIMIT).

Det er ikke avanceret... det er MEGET bedre...

> Man kan også kombinere de to metoder, hvis man både vil have performance og
> vil have mulighed for f.eks. direkte opslag på en bestemt side.

Jamen din har en "dårlig" performance? Det er jo bare dårlige
forklaringer du kommer med? Indrøm fejlen? :P

> Forskellen mellem de to metoder er ikke så stor, hvis serveren er ubelastet
> og mysql kører på samme maskine som webserveren, men hvis systemet er
> belastet, så er indeksopslag klart at foretrække frem for sekventiel
> gennembladring af records.

Nej... for du sorterer også ved LIMIT opslag... jeg har netop gennemført
en test... ALLE scripts er tilgængelige hvis det skal ønkes (smid en
mail) ... inklusiv databasen.


Opsummering af testen...
Følgende tabel blev oprette i en UBELASTET server
CREATE TABLE test (
id int(11) NOT NULL auto_increment,
testval varchar(255) NOT NULL default '',
PRIMARY KEY (id)
) TYPE=MyISAM;

Følgende query blev brugt til at indsætte 1340000
mysql_query("INSERT INTO test (testval) VALUES
('".md5(uniqid(rand(),1))."')");

Derefter lavede jeg 2 scripts..
Begge kan sendes hvis de ønskede...
Men kort sagt... begge scripts lavede et 100 UNIKKE id'ere (i en
forløkke).. here er WHERE sætninger på de 2...

Lars: id > ".rand(0,1300000)." ORDER BY id LIMIT 200
Mig: ORDER BY id LIMIT ".rand(0,1300000).", 200

Resten af scriptet var identisk!

Regner ikke med der skulle være noget ivejen med disse??

Testen blev følgende - førstnævnte er Lars's:

1. 0,3598s 0,0202s
2. 0,3607s 0,0171s
3. 0,3756s 0,0168s
4. 0,3542s 0,0174s
5. 0,3553s 0,0165s

Altså det er MEGET hurtigere at bruge et LIMIT med start ved og antal...
(hvilket også er logisk....)

SCRIPTS kan fåes via e-mail johan (at) contillion.com

mvh
Johan

---

Johan Holst Nielsen wrote:
> Det passer jo ikke!? Jeg vil gerne se beviser for dette... for så kan du
> ikke lave dine queries ordentlig...

Det er generelt almindeligt akcepteret, at index-baserede opslag er
hurtigere end sekventielle gennemløb af data. Hvis du f.eks. har 1 million
records, så tager det op til 20 opslag i indekset før du har en bestemt
record (ofte mindre, hvis indekset er et b-træ eller lign.). Hvis du så vil
gennemse f.eks. 100 records i en rækkefølge sorteret efter det samme eller
et andet indeks, kommer der op til 100 opslag i indekset (ofte dog mindre).
I alt altså op mod 120 opslag.

Hvis du derimod slår direkte op på den første record, du vil have vist,
kommer der max 20 opslag før brugeren ser sin første record. 20 er mindre
end 120. q.e.d.

>> men hvis
>> systemet er belastet, så er indeksopslag klart at foretrække frem for
>> sekventiel gennembladring af records.
> Nej... for du sorterer også ved LIMIT opslag...

Du burde læse lidt om fordelen ved indeksering, hvordan en database tilgår
harddisken m.v. Der er altså en grund til, at man laver indekser på sin
database.

> Lars: id > ".rand(0,1300000)." ORDER BY id LIMIT 200
> Mig: ORDER BY id LIMIT ".rand(0,1300000).", 200

Her har du vist lavet en fejl. Hvis du f.eks. vil vise records 100-120, skal
du med min metode lave en forespørgsel, der returnerer de første 20 records
efter en vis værdi i indekset, og det sekventielle gennemløb er at spørge
efter record nummer 100-120 efter en værdi i indekset. De to metoder
adskiller sig udelukkende ved, at det sekventielle gennemløb tilføjer et
gennemløb af ekstra records.

Lars.

--
Freelance programmør
Programmering mod timebetaling

---

Lars Dybdahl wrote:
> Du burde læse lidt om fordelen ved indeksering, hvordan en database tilgår
> harddisken m.v. Der er altså en grund til, at man laver indekser på sin
> database.
>
>
>>Lars: id > ".rand(0,1300000)." ORDER BY id LIMIT 200
>>Mig: ORDER BY id LIMIT ".rand(0,1300000).", 200
>
>
> Her har du vist lavet en fejl. Hvis du f.eks. vil vise records 100-120, skal
> du med min metode lave en forespørgsel, der returnerer de første 20 records
> efter en vis værdi i indekset, og det sekventielle gennemløb er at spørge
> efter record nummer 100-120 efter en værdi i indekset. De to metoder
> adskiller sig udelukkende ved, at det sekventielle gennemløb tilføjer et
> gennemløb af ekstra records.


Jeg forstår ikke hvad du mener? Fortæl mig hvorledes jeg så skal lave
querien?

Pt. returnerer du altså en værdi ifølge et index.... ID er netop et
index (primært index)... altså så vælger jeg at returnerer 200 istedet
for 20? Det er for at teste performance... ikke andet...

Det samme gør jeg med limit....

Fortæl mig hvorledes jeg så skal opbygge den query du mener... du fik
database opbygningen i den tidligere... jeg ønsker at hente "testval" ud
200 gang.... ud fra en start fra et tilfældig primært index!

mvh
Johan

---

Johan Holst Nielsen wrote:
> Jeg forstår ikke hvad du mener? Fortæl mig hvorledes jeg så skal lave
> querien?

Din metode:

select *
from postnumre
where postnumer>="2000"
order by efternavn
limit 200,10

Min metode:

select *
from postnumre
where efternavn>="2800"
order by efternavn
limit 0,10

Jeg håber, du ser forskellen.

Hilsen,

Lars.

--
Freelance programmør
Programmering mod timebetaling

---

Lars Dybdahl wrote:
> Johan Holst Nielsen wrote:
>
>>Jeg forstår ikke hvad du mener? Fortæl mig hvorledes jeg så skal lave
>>querien?
>
> select *
> from postnumre
> where postnumer>="2000"
> order by efternavn
> limit 200,10

Nej, det er ikke min metode.
Min metode er helt fra start.. at finde ud af hvad man indexerer
efter.... altså f.eks. ID eller postnumre...
Derved skal jeg ikke bruge en >= som du prøver på... i stedet ville det
f.eks. se således ud

select * from postnumre
where keywords like '%{$_GET['keywords']}%'
order by keywords
limit $_GET['offset'],10


> Min metode:
>
> select *
> from postnumre
> where efternavn>="2800"
> order by efternavn
> limit 0,10

Og din ville være
select * from postnumre
where keywords >= '%{$_GET['lastRow']}%'
order by keywords
limit 0,10

mvh
Johan

---

Johan Holst Nielsen wrote:
> select * from postnumre
> where keywords like '%{$_GET['keywords']}%'
> order by keywords
> limit $_GET['offset'],10

Denne løsning virker kun, hvis keywords er en unik id - ellers kan du ikke
påregne, at resultatet af af denne query giver samme rækkefølge hver gang,
og dermed kan de forskellige records hoppe fra side til side.

Hvis du vil have et konsistent brugerinterface, der generelt virker med
MySQL, også fremtidige versioner, så skal du sortere efter en unik nøgle,
og så er vi tilbage i postnummer-eksemplet, som jeg gav.

Det eksempel, du har givet foroven, laver potentielt et grusomt gennemløb af
ALLE records (evt. af alle poster i indekset), for at kunne sammenligne med
parameteren keywords. Hvis det er det, du vil, så kan jeg godt forstå din
argumentation, eftersom at dit SQL statement allerede fra start er
horribelt ved større datamængder. Du kan ikke få en ordentlig performance
på en stor database med den slags sql statements, hvis brugeren selv kan
indtaste keywords parameteren.

Min argumentation er umiddelbart kun gyldig, hvis søgningen i sig selv er
indekseret. Jeg er vandt til databaser med tabeller i Gigabytes størrelse
på 64 og 128MB RAM, og jeg er vandt til, at et SQL statement som dit ville
medføre at computeren bliver så belastet, at det hurtigste er at slukke og
tænde for serveren igen for at sikre driften. Hvis du kører på et webhotel,
deler du RAM'en med andre brugere, og der kan være mange samtidige brugere
på systemet, så her er problematikken meget sammenlignelig, allerede ved
mindre databaser.

Hovedparten af database udgøres af en enkelt tabel, og det er denne tabel,
der foretages flest søgninger i. Hvis jeg fyrer bare en enkelt SQL
statement af, som skal gennemløbe alle records, ligesom dit sql statement,
så hænger maskinen i timer. Når det sker, plejer jeg at slukke for maskinen
og tænde den igen - det tager simpelthen for lang tid at prøve at logge ind
som root på konsollen. Til gengæld afvikles mine forespørgsler typisk på
under 0,1 sekund, fordi de er skrevet rigtigt.

En ting, der kunne øge performance ganske gevaldigt på din søgning, og
samtidigt give et konsistent brugerinterface, er at hentef.eks. op til 100
søgeresultater, og gemme dem i en separat tabel som søgeresultat, og så
bruge den tabel til bladringsformål. Her vil du få en reproducerbar
rækkefølge, og du vil faktisk kunne specificere intervallet endnu bedre
(her for visning af resultaterne 20-29):

select *
from soegeresultat
where index>=20 and index<30
order by index

> Og din ville være
> select * from postnumre
> where keywords >= '%{$_GET['lastRow']}%'
> order by keywords
> limit 0,10

Nej. Sådan et grufuldt sql statement ville jeg gøre alt for ikke at lave.

Lars.

--
Freelance programmør
Programmering mod timebetaling

---

Michael Korsgaard wrote:
> ?page=2 på de næste. Hvordan gør man det. det skal tage fra en mysql
> database? Der skal være 20 på hver side!

Du skal kigge lidt på LIMIT i forbindelse med sql-selects.
f.eks. kan du hente de første 20 med "select * from tabel limit 0,20"
og de næste 20 med limit "select * from tabel 20,20"

Du kan finde mere information på www.mysql.com

Mvh
Søren

---

Jeg skrev:

> og de næste 20 med limit "select * from tabel 20,20"

Og mente:
"select * from tabel limit 20,20"

Mvh
Søren

---

Kan man få "næste 20" med lnk til at stå der automatisk hvis der er flere i
databasen?
"Søren Nielsen" <spamREMOVETHIS@REMOVETHISn-crypt.dk> skrev i en meddelelse
news:3ec24ccd$0$24643$edfadb0f@dread14.news.tele.dk...
> Jeg skrev:
>
> > og de næste 20 med limit "select * from tabel 20,20"
>
> Og mente:
> "select * from tabel limit 20,20"
>
> Mvh
> Søren
>

---

"Michael Korsgaard" <miv_k@hotmail.com> wrote in message
news:3ec24d91$0$288$ba624c82@nntp05.dk.telia.net...
> Kan man få "næste 20" med lnk til at stå der automatisk hvis der er flere
i
> databasen?

Ja det kan man godt.
Hvor langt er du kommet med selv at kode det?
Med andre ord - hvilken del kode skal du have hjælp med?


Og kan man få dig til at lære minimal citationsteknik?
http://www.usenet.dk/netikette/citatteknik.html


Mvh
Jimmy

---

Michael Korsgaard wrote:
> Kan man få "næste 20" med lnk til at stå der automatisk hvis der er
> flere i databasen?

Læg 20 til den count naturligvis har oprettet til at holde styr på, hvor
langt du er nået

--
Take Care
Kim Emax - Freelance programmør
http://www.emax.dk - http://www.ayianapa.dk
Køb din vin online på http://www.gmvin.dk,
Danmarks måske mest avancerede VinWebShop

---

Michael Korsgaard wrote:

> Kan man få "næste 20" med lnk til at stå der automatisk hvis der er flere i
> databasen?

For at vide hvor mange rækker der i alt er skal du kigge nærmere på
SQL_CALC_FOUND_ROWS som du kan læse mere om her:
http://www.mysql.com/doc/en/SELECT.html

Eller på php.net:
http://dk.php.net/manual/en/function.mysql-num-rows.php
(Kig i brugernes kommentarer)

Mvh
Søren

---

Søren Nielsen <spamREMOVETHIS@REMOVETHISn-crypt.dk> skrev i
dk.edb.internet.webdesign.serverside.php:

>Michael Korsgaard wrote:

>> Kan man få "næste 20" med lnk til at stå der automatisk hvis der er flere i
>> databasen?

>For at vide hvor mange rækker der i alt er skal du kigge nærmere på
>SQL_CALC_FOUND_ROWS som du kan læse mere om her:
>http://www.mysql.com/doc/en/SELECT.html

Desværre kræver det så at man kører MySQL 4.0 for at kunne udnytte den
funktion.

Jeg plejer at hente LIMIT+1 rækker fra tabellem, men kun vise LIMIT
antal rækker i søgeresultatet. På den måde ved jeg altid, om der
kommer minimum én række mere og kan så indsætte en 'Næste'-knap på
siden.

Hvis antallet af returnerede rækker er mindre eller lig med LIMIT, så
er der ikke flere rækker i resultatet.

--
Jens Tønnesen - http://www.pressefoto.dk

---

Jens Tønnesen <usenet@pressefoto.invalid> writes:

> >For at vide hvor mange rækker der i alt er skal du kigge nærmere på
> >SQL_CALC_FOUND_ROWS som du kan læse mere om her:
> >http://www.mysql.com/doc/en/SELECT.html
>
> Desværre kræver det så at man kører MySQL 4.0 for at kunne udnytte den
> funktion.

Så er det heldigt, at der findes "SELECT count(*)"

--
Med venlig hilsen
- Jacob Atzen

---

Jacob Atzen wrote:

> Så er det heldigt, at der findes "SELECT count(*)"

Det er pænere for databasen at benytte sig af mysql_num_rows(), når kaldet
nu en gang er foretaget, derved sparer man et kald.

--
Take Care
Kim Emax - Freelance programmør
http://www.emax.dk - http://www.ayianapa.dk
Køb din vin online på http://www.gmvin.dk,
Danmarks måske mest avancerede VinWebShop

---

On Wed, 14 May 2003 22:26:22 +0200, "Kim Emax"
<newsgroup@remove-emax.dk> wrote:

>> Så er det heldigt, at der findes "SELECT count(*)"
>Det er pænere for databasen at benytte sig af mysql_num_rows(), når kaldet
>nu en gang er foretaget, derved sparer man et kald.

Det forudsætter så at man hiver hele datasættet ud. Hvis man LIMIT'er
til fx 20 rækker, så vil mysql_num_rows() jo max være 20.

COUNT(*) for en enkelt tabel uden nogen WHERE er i øvrigt for MyISAMs
vedkommende voldsomt hurtig, da den blot henter dataen direkte fra
tabelinformationen, fremfor at den skal løbe indexes eller selve
datafilen igennem.

--
- Peter Brodersen

---

Peter Brodersen wrote:

> Det forudsætter så at man hiver hele datasættet ud. Hvis man LIMIT'er
> til fx 20 rækker, så vil mysql_num_rows() jo max være 20.

Right, var lige gået væk fra limit, da jeg tænkte den tanke Tænkte på
den situation, hvor man vil ha "du har fundet XX matches" frem

> COUNT(*) for en enkelt tabel uden nogen WHERE er i øvrigt for MyISAMs
> vedkommende voldsomt hurtig, da den blot henter dataen direkte fra
> tabelinformationen, fremfor at den skal løbe indexes eller selve
> datafilen igennem.

Jeps, i limit situationen er den bedre...

--
Take Care
Kim Emax - Freelance programmør
http://www.emax.dk - http://www.ayianapa.dk
Køb din vin online på http://www.gmvin.dk,
Danmarks måske mest avancerede VinWebShop