---

Hejsa.

Hvilken funktion kan jeg bruge til at trække fx de 10 nyeste (efter
dato) indlæg i en MySql db ?

Med venlig hilsen
Jesper L Hansen

---

On Sun, 24 Jun 2001 17:49:56 +0200, Jesper L Hansen <lismoes@mail.dk>
wrote:

>Hvilken funktion kan jeg bruge til at trække fx de 10 nyeste (efter
>dato) indlæg i en MySql db ?

mysql_query()

Brug limit 0,10 i slutningen af din SQL sætning mener jeg det er.

Mvh. / Regards Stefan Bruhn
--
<?$email = unserialize("a:15:{i:0;i:115;i:1;i:116;i:2;i:101;i:3;i:102
;i:4;i:97;i:5;i:110;i:6;i:64;i:7;i:98;i:8;i:114;i:9;i:117;i:10;i:104
;i:11;i:110;i:12;i:46;i:13;i:116;i:14;i:111;}");
for ($i=0;$i<=15;$i++) {echo chr($email[$i]);}?>

---

"Stefan Bruhn" <news003@3x7.dk> skrev i en meddelelse
news:f13cjt46e852pc6h0q7qo8h8stv77u0h3l@ghashul.dk...

> >Hvilken funktion kan jeg bruge til at trække fx de 10 nyeste (efter
> >dato) indlæg i en MySql db ?
>
> mysql_query()

Ja, eller mysql_unbuffered_query() for den sags skyld.

--
Mvh. Jonas Delfs, http://delfs.dk
e72bd3e51a7937c87d28b85d677a97b2

---

In article <9h538i$du9$1@sunsite.dk>, "Jonas Delfs"
<jonas@nospam.delfs.dk> wrote:

>> mysql_query()
>
> Ja, eller mysql_unbuffered_query() for den sags skyld.

Uden at det dog ville give andet end ulemper i hint tilfælde.

/A
--
Nu med transport til Midtfynsfestival -- www.midtfyn.com

---

"Anders Johannsen" <anders@ignition.dk> skrev i en meddelelse
news:20010624.183454.165344818.484@ignition.dk...

> >> mysql_query()
> >
> > Ja, eller mysql_unbuffered_query() for den sags skyld.
>
> Uden at det dog ville give andet end ulemper i hint tilfælde.

Som hvad?
Det er korrekt at det ikke vil give fordele i forhold til mysql_query(), men
eftersom han lige præcist definerer hvor mange rækker han vil ha' ud, er
problemet med at mysql_num_rows() ikke virker, jo ligemeget.
Så ulemper? -næppe...

--
Mvh. Jonas Delfs, http://delfs.dk
e72bd3e51a7937c87d28b85d677a97b2

---

In article <9h56r2$cmp$1@sunsite.dk>, "Jonas Delfs"
<jonas@nospam.delfs.dk> wrote:

>> > Ja, eller mysql_unbuffered_query() for den sags skyld.
>>
>> Uden at det dog ville give andet end ulemper i hint tilfælde.
>
> Som hvad?
> Det er korrekt at det ikke vil give fordele i forhold til mysql_query(),
> men eftersom han lige præcist definerer hvor mange rækker han vil ha'
> ud, er problemet med at mysql_num_rows() ikke virker, jo ligemeget. Så
> ulemper? -næppe...

At
- man er afskåret fra at bruge mysql_num_rows()
- man ikke kan fyre nye SQL forespørgsler af førend resultatet er fuldt
hentet
- funktionskaldet er først understøttet fra og med 4.0.6
- funktionskaldet er _længere_
- der ikke opnås nogen fordele iøvrigt

ser jeg som ulemper.

/A
--
Nu med transport til Midtfynsfestival -- www.midtfyn.com

---

"Anders Johannsen" <anders@ignition.dk> skrev i en meddelelse
news:20010624.195415.396473730.484@ignition.dk...

> At
> - man er afskåret fra at bruge mysql_num_rows()

Ja, på lige præcist dette query, hvori han jo HAR defineret hvor mange
resultater han ønsker retur.

> - man ikke kan fyre nye SQL forespørgsler af førend resultatet er fuldt
> hentet

.... og det har han øjensynligt brug for?

> - funktionskaldet er først understøttet fra og med 4.0.6

Ja - han skal naturligvis ikke bruge funktionen hvis han ikke kører
PHP4.0.6. Men gør han det, er der jo ikke nogen problemer.

> - funktionskaldet er _længere_

Længe leve den dovne programmør.

> - der ikke opnås nogen fordele iøvrigt

Har jeg også skrevet.
Dog passer det ikke helt: mysql_unbuffered_query() skulle være hurtigere.

> ser jeg som ulemper.

Jeg har jo netop skrevet at der ikke var nogen større fordele ved brug af
mysql_unbuffered_query() i dette tilfælde, og mit svar var egentligt bare
for at gøre opmærksom på at det bare er en funktion der kan sende et query
der skal til - ikke en PHP-funktion.

--
Mvh. Jonas Delfs, http://delfs.dk
e72bd3e51a7937c87d28b85d677a97b2

---

In article <9h5aq2$6do$1@sunsite.dk>, "Jonas Delfs"
<jonas@nospam.delfs.dk> wrote:

>> - der ikke opnås nogen fordele iøvrigt
>
> Har jeg også skrevet.
> Dog passer det ikke helt: mysql_unbuffered_query() skulle være
> hurtigere.

Idet ?

/A

---

"Anders Johannsen" <anders@ignition.dk> skrev i en meddelelse
news:20010624.214517.2001229904.484@ignition.dk...

> >> - der ikke opnås nogen fordele iøvrigt
> >
> > Har jeg også skrevet.
> > Dog passer det ikke helt: mysql_unbuffered_query() skulle være
> > hurtigere.
>
> Idet ?

Idet MySQL ikke skal bruge ressourcer på at buffe.

--
Mvh. Jonas Delfs, http://delfs.dk
e72bd3e51a7937c87d28b85d677a97b2

---

In article <9h5h7j$ojj$1@sunsite.dk>, "Jonas Delfs"
<jonas@nospam.delfs.dk> wrote:

>> > Har jeg også skrevet.
>> > Dog passer det ikke helt: mysql_unbuffered_query() skulle være
>> > hurtigere.
>>
>> Idet ?
>
> Idet MySQL ikke skal bruge ressourcer på at buffe.

Buffering foregår under alle omstændigheder _efter_ resultatet er blevet
overført til PHP.

/A
--
Nu med transport til Midtfynsfestival -- www.midtfyn.com

---

Anders Johannsen <anders@ignition.dk> wrote:

>> Idet MySQL ikke skal bruge ressourcer på at buffe.

> Buffering foregår under alle omstændigheder _efter_ resultatet er blevet
> overført til PHP.

Men det ændrer jo ikke på det faktum, at det rent faktisk, under alle
omstændigheder, vil gå hurtigere uden at buffe outputtet. Det var jo
egentlig det, der var Jonas' påstand til at starte med.

--
Christian Jørgensen | "Ford, you're turning into a penguin"
http://www.razor.dk | "Stop it"

---

In article <28397912.NvrqWZg68T@flaf>, "Christian Joergensen"
<mail@phpguru.dk> wrote:

> Anders Johannsen <anders@ignition.dk> wrote:

>> Buffering foregår under alle omstændigheder _efter_ resultatet er
>> blevet overført til PHP.
>
> Men det ændrer jo ikke på det faktum, at det rent faktisk, under alle
> omstændigheder, vil gå hurtigere uden at buffe outputtet. Det var jo
> egentlig det, der var Jonas' påstand til at starte med.

Det er det tilsyneladende uomtvistelige faktum, som jeg gerne vil have
forklaret.

/A
--
Nu med transport til Midtfynsfestival -- www.midtfyn.com

---

> >> - der ikke opnås nogen fordele iøvrigt
> >
> > Har jeg også skrevet.
> > Dog passer det ikke helt: mysql_unbuffered_query() skulle være
> > hurtigere.
>
> Idet ?


Lad os tage et ekstremt eksempel:

Vi har en database (DB), hvor vi ønsker at køre en bestemt query (Q). Dette
gøres på 10 sekunder, da DB er stor.

Mængden af uddata (D) er ligeledes stor, så det tager 10 sekunder at sende
D.

Hvis vi bruger mysql_query(), vil vi altså først vente på Q i DB (10
sekunder), og derefter på at D bliver sendt.

Hvis vi bruger mysql_unbuffered_query(), vil vi få det første sæt data med
det samme. Derfor vil vi kun bruge en anelse over 10 sekunder *i alt* på at
foretage hele forespørgslen. Fordi vi ikke venter på begge begivenheder, de
foregår "samtidig".

--
Regards, Christian Iversen [FIDUSO]
Flawless.Dk: [http://domains.flawless.dk]
Do you have a (broken?) IBM75GXP Drive?
Please go to [http://ibm.flawless.dk]

---

In article <9h5heq$1f6j$1@news.cybercity.dk>, "Christian Iversen"
<iversen@it.dk> wrote:

> Lad os tage et ekstremt eksempel:
>
> Vi har en database (DB), hvor vi ønsker at køre en bestemt query (Q).
> Dette gøres på 10 sekunder, da DB er stor.
>
> Mængden af uddata (D) er ligeledes stor, så det tager 10 sekunder at
> sende D.
>
> Hvis vi bruger mysql_query(), vil vi altså først vente på Q i DB (10
> sekunder), og derefter på at D bliver sendt.
>
> Hvis vi bruger mysql_unbuffered_query(), vil vi få det første sæt data
> med det samme. Derfor vil vi kun bruge en anelse over 10 sekunder *i
> alt* på at foretage hele forespørgslen. Fordi vi ikke venter på begge
> begivenheder, de foregår "samtidig".

Nej

MySQL begynder først at sende data når hele resultatet er allokeret, dvs.
når queryen er udført. På den måde fungerer mysql_query() og
mysql_buffered_query() ens.

Forskellen er at mysql_buffered_query() returnerer så snart resultatet er
allokeret i MySQL, men mysql_query() også overfører hele resultatet til
PHP førend den returnerer.

Altså:
   med buffer er query() kaldet afsluttet efter 10 sekunder
   uden buffer varer det 20 sekunder

mysql_buffered_query() skal altså stadigvæk bruge 10 sekunder ekstra på
hente resultatet, og ved begge metoder er tidsforbruget stadigvæk 20
sekunder

Forskellen er, at hukommelsesforbruget uden buffer ved _store_
resultatsæt er mindre.

/A
--
Nu med transport til Midtfynsfestival -- www.midtfyn.com

---

"Anders Johannsen" <anders@ignition.dk> skrev i en meddelelse
news:20010624.230437.501772890.484@ignition.dk...

> MySQL begynder først at sende data når hele resultatet er allokeret, dvs.
> når queryen er udført. På den måde fungerer mysql_query() og
> mysql_buffered_query() ens.
>
> Forskellen er at mysql_buffered_query() returnerer så snart resultatet er
> allokeret i MySQL, men mysql_query() også overfører hele resultatet til
> PHP førend den returnerer.
>
> Altså:
> med buffer er query() kaldet afsluttet efter 10 sekunder
> uden buffer varer det 20 sekunder
>
> mysql_buffered_query() skal altså stadigvæk bruge 10 sekunder ekstra på
> hente resultatet, og ved begge metoder er tidsforbruget stadigvæk 20
> sekunder

Jeg må indrømme at jeg ikke kan hverken be- eller afkræfte det du påstår nu.

> Forskellen er, at hukommelsesforbruget uden buffer ved _store_
> resultatsæt er mindre.

Dog kan quotede påstand slet ikke give mening.
Hvorfor skulle MySQL kun spare hukommelse hvis man får store resultatsæt som
resultat? -den sparer naturligvis også ved små, men tilsvarende mindre er
hukommelses besparrelsen jo også. - og den er vel værd at tage med.

--
Mvh. Jonas Delfs, http://delfs.dk
e72bd3e51a7937c87d28b85d677a97b2

---

In article <9h5lc6$2t8$1@sunsite.dk>, "Jonas Delfs"
<jonas@nospam.delfs.dk> wrote:

>> Forskellen er, at hukommelsesforbruget uden buffer ved _store_
>> resultatsæt er mindre.
>
> Dog kan quotede påstand slet ikke give mening. Hvorfor skulle MySQL kun
> spare hukommelse hvis man får store resultatsæt som resultat? -den
> sparer naturligvis også ved små, men tilsvarende mindre er hukommelses
> besparrelsen jo også. - og den er vel værd at tage med.

Det er _stadigvæk_ ikke MySQL det handler om. Forskellen på bufferen og
unbuffered ligger kun i PHP.

Det er stort set gratis smide et mindre resultatsæt i bufferen, og det gør
det iøvrigt hurtigere at hente rækker vha. mysql_fetch_* bagefter --
derfor gøres det som standard. mysql_unbuffered_query() giver kun fordele
i specielle tilfælde

/A
--
Nu med transport til Midtfynsfestival -- www.midtfyn.com

---

"Anders Johannsen" <anders@ignition.dk> skrev i en meddelelse
news:20010624.233007.1186090428.484@ignition.dk...

> Det er _stadigvæk_ ikke MySQL det handler om. Forskellen på bufferen og
> unbuffered ligger kun i PHP.

Godt så - så lærte jeg også noget i dag.
Men tilbage til den oprindelige grund til overhovedet at nævne
mysql_unbuffered_query(), så var det jo ikke et oplæg til debat om
fordele/ulemper, men egentligt bare en måde at forklare at det ikke er en
funktion, men blot SQL/et query der giver ønskede resultat. Dette har jeg
også nævnt før.

EOD.

--
Mvh. Jonas Delfs, http://delfs.dk
e72bd3e51a7937c87d28b85d677a97b2

---

In article <9h5mte$60j$1@sunsite.dk>, "Jonas Delfs"
<jonas@nospam.delfs.dk> wrote:

> Godt så - så lærte jeg også noget i dag. Men tilbage til den oprindelige
> grund til overhovedet at nævne mysql_unbuffered_query(), så var det jo
> ikke et oplæg til debat om fordele/ulemper, men egentligt bare en måde
> at forklare at det ikke er en funktion, men blot SQL/et query der giver
> ønskede resultat. Dette har jeg også nævnt før.

Det fremgik ikke ...

EOD herfra også.

/A
--
Nu med transport til Midtfynsfestival -- www.midtfyn.com

---

> > Hvis vi bruger mysql_unbuffered_query(), vil vi få det første sæt data
> > med det samme. Derfor vil vi kun bruge en anelse over 10 sekunder *i
> > alt* på at foretage hele forespørgslen. Fordi vi ikke venter på begge
> > begivenheder, de foregår "samtidig".
>
> Nej

Jo!

Grunden til at mit handle er Flawless, er at jeg ikke tager fejl. Aldrig.


> MySQL begynder først at sende data når hele resultatet er allokeret, dvs.
> når queryen er udført. På den måde fungerer mysql_query() og
> mysql_buffered_query() ens.

Forkert.

> Forskellen er at mysql_buffered_query() returnerer så snart resultatet er
> allokeret i MySQL, men mysql_query() også overfører hele resultatet til
> PHP førend den returnerer.

Delvis rigtigt.

> Altså:
> med buffer er query() kaldet afsluttet efter 10 sekunder
> uden buffer varer det 20 sekunder

Forkert.

> mysql_buffered_query() skal altså stadigvæk bruge 10 sekunder ekstra på
> hente resultatet, og ved begge metoder er tidsforbruget stadigvæk 20
> sekunder
>
> Forskellen er, at hukommelsesforbruget uden buffer ved _store_
> resultatsæt er mindre.

Det sidste her er rigtigt.

Jeg vil nu lige citere manualen:

"...On the other hand, you can start working on the result set
immediately after the first row has been retrieved: you don't
have to wait *until the complete SQL query has been performed*. "

Nu håber jeg altså virkelig at manualen har ret

--
Regards, Christian Iversen [FIDUSO]
Flawless.Dk: [http://domains.flawless.dk]
Do you have a (broken?) IBM75GXP Drive?
Please go to [http://ibm.flawless.dk]

---

In article <9h63ri$2c1p$1@news.cybercity.dk>, "Christian Iversen"
<iversen@it.dk> wrote:

>> > Hvis vi bruger mysql_unbuffered_query(), vil vi få det første sæt
>> > data med det samme. Derfor vil vi kun bruge en anelse over 10
>> > sekunder *i alt* på at foretage hele forespørgslen. Fordi vi ikke
>> > venter på begge begivenheder, de foregår "samtidig".
>>
>> Nej
>
> Jo!

Nu har du tvunget mig til at gå lidt i dybden med sagen, og resultatet
følger her:

Hvis vi kigger på forskellen mellen PHP-funktionerne mysql_query() og
mysql_unbuffered_query() på C niveau, vil man se at begge resulterer i
følgende kald i MySQL C api:

   if (mysql_real_query(&mysql->conn, (*query)->value.str.val, (*query)->value.str.len)!=0) {
      RETURN_FALSE;

Den eneste forskel ligger i de følgende linjer:

   if(use_store == MYSQL_USE_RESULT) {
      mysql_result=mysql_use_result(&mysql->conn);
   } else {
      mysql_result=mysql_store_result(&mysql->conn);
   }

Hvor use_store er defineret som MYSQL_USE_RESULT hvis man har kaldt
mysql_unbuffered_query() i PHP.

Både buffered og unbuffered benytter sig altså af _nøjagtig_ samme query
metode i MySQLs API. Der er således ikke tale om nogen ting der på magisk
vis foregår samtidig.

Konsulter evt. MySQLs manual om forskellen mellem mysql_use_result() og
mysql_store_result()

> Grunden til at mit handle er Flawless, er at jeg ikke tager fejl.
> Aldrig.
> Forkert.
> Delvis rigtigt.
> Forkert.
> Det sidste her er rigtigt.
> Nu håber jeg altså virkelig at manualen har ret



/A
--
Nu med transport til Midtfynsfestival -- www.midtfyn.com

---

> >> > Hvis vi bruger mysql_unbuffered_query(), vil vi få det første sæt
> >> > data med det samme. Derfor vil vi kun bruge en anelse over 10
> >> > sekunder *i alt* på at foretage hele forespørgslen. Fordi vi ikke
> >> > venter på begge begivenheder, de foregår "samtidig".
> >>
> >> Nej
> >
> > Jo!
>
> Nu har du tvunget mig til at gå lidt i dybden med sagen, og resultatet
> følger her:

Jeg HAR sagt jeg er Flawless. Basta!

> Hvis vi kigger på forskellen mellen PHP-funktionerne mysql_query() og
> mysql_unbuffered_query() på C niveau, vil man se at begge resulterer i
> følgende kald i MySQL C api:
>
> if (mysql_real_query(&mysql->conn, (*query)->value.str.val,
(*query)->value.str.len)!=0) {
> RETURN_FALSE;
>
> Den eneste forskel ligger i de følgende linjer:
>
> if(use_store == MYSQL_USE_RESULT) {
> mysql_result=mysql_use_result(&mysql->conn);
> } else {
> mysql_result=mysql_store_result(&mysql->conn);
> }
>
> Hvor use_store er defineret som MYSQL_USE_RESULT hvis man har kaldt
> mysql_unbuffered_query() i PHP.

Jep, klart så langt.

> Både buffered og unbuffered benytter sig altså af _nøjagtig_ samme query
> metode i MySQLs API. Der er således ikke tale om nogen ting der på magisk
> vis foregår samtidig.

Forhastet konklusion!!

Ser du, efter en mysql_real_query(), *skal* man benytte enten
mysql_use_result(), eller mysql_store_result().

> Konsulter evt. MySQLs manual om forskellen mellem mysql_use_result() og
> mysql_store_result()

Det har jeg gjort.

mysql_store_result() fortæller MySQL at man gerne vil have buffered hele
svaret.

mysql_use_result() fortæller MySQL at *man gerne vil have svaret direkte*.

Her er hvad manualen siger (den du støtter dig til

"
mysql_use_result() initiates a result set retrieval but does not actually
read the result set into the client like mysql_store_result() does. Instead,
each row must be retrieved individually by making calls to
mysql_fetch_row().
This reads the result of a query directly from the server without storing
it in a temporary table or local buffer, which is somewhat faster and uses
much less memory than mysql_store_result(). The client will only allocate
memory for the current row and a communication buffer that may grow up to
max_allowed_packet bytes.
"



> > Grunden til at mit handle er Flawless, er at jeg ikke tager fejl.
> > Aldrig.
> > Forkert.
> > Delvis rigtigt.
> > Forkert.
> > Det sidste her er rigtigt.
> > Nu håber jeg altså virkelig at manualen har ret
>
>

"Den der smiler sidst, ler bedst"... okay, tæt på originalen i det
mindste...

--
Regards, Christian Iversen [FIDUSO]
Flawless.Dk: [http://domains.flawless.dk]
Do you have a (broken?) IBM75GXP Drive?
Please go to [http://ibm.flawless.dk]

---

In article <9h7a27$tfp$1@news.cybercity.dk>, "Christian Iversen"
<iversen@it.dk> wrote:

>> Nu har du tvunget mig til at gå lidt i dybden med sagen, og resultatet
>> følger her:
>
> Jeg HAR sagt jeg er Flawless. Basta!

Det er nok svært at blive enige på det grundlag

> Forhastet konklusion!!
>
> Ser du, efter en mysql_real_query(), *skal* man benytte enten
> mysql_use_result(), eller mysql_store_result().

Ja ? Det viser det jeg saksede fra php_mysql.c med alt ønskelig
tydelighed.

> mysql_store_result() fortæller MySQL at man gerne vil have buffered hele
> svaret.
>
> mysql_use_result() fortæller MySQL at *man gerne vil have svaret
> direkte*.

Korrekt. Men det sker jo først efter mysql_real_query() returnerer,
hvormed hele resultatet i begge tilfælde er allokeret. De to funktioner
fortæller udelukkende MySQL hvordan man skal håndtere den efterfølgende
streaming

   mysql_store_result(): Hele resultatet hentes med det samme, hvorefter
   efterfølgende kald til mysql_fetch_* hentes fra bufferen.

   mysql_use_result(): Forbindelsen initieres, men data hentes _først_ ved
   kald til mysql_fetch_*

Dit eksempel vil således ikke give den nævnte tidsbesparelse, og _aldrig_
af de årsager, som du anfører.

HA!

/A
--
Nu med transport til Midtfynsfestival -- www.midtfyn.com

---

> >> Nu har du tvunget mig til at gå lidt i dybden med sagen, og resultatet
> >> følger her:
> >
> > Jeg HAR sagt jeg er Flawless. Basta!
>
> Det er nok svært at blive enige på det grundlag

Du har helt ret. Det er også en uvane...

> > Forhastet konklusion!!
> >
> > Ser du, efter en mysql_real_query(), *skal* man benytte enten
> > mysql_use_result(), eller mysql_store_result().
>
> Ja ? Det viser det jeg saksede fra php_mysql.c med alt ønskelig
> tydelighed.

Det har du helt ret i... hmm... jeg vrøvler en anelse her.

Min oprindelige pointe var at komme med forklaringen på store/use
lige efter.

> > mysql_store_result() fortæller MySQL at man gerne vil have buffered hele
> > svaret.
> >
> > mysql_use_result() fortæller MySQL at *man gerne vil have svaret
> > direkte*.
>
> Korrekt. Men det sker jo først efter mysql_real_query() returnerer,
> hvormed hele resultatet i begge tilfælde er allokeret. De to funktioner
> fortæller udelukkende MySQL hvordan man skal håndtere den efterfølgende
> streaming

Næ hov!

Manualen siger:

"This reads the result of a query directly from the server without storing
it in a temporary table or local buffer, ..."

Der kan altså *ikke* være tale om at resultatet er allokeret

Der siges også:

"The client will only allocate memory for the current row ..."

Jeg kan altså ikke se hvordan hele resultatet kan allokeres først, hvis
ellers manualen har ret. Jeg siger ikke at jeg har fejllæst manualen,
men jeg kunne godt tænke mig at vide hvordan DU kan være så skråsikker?

> mysql_store_result(): Hele resultatet hentes med det samme, hvorefter
> efterfølgende kald til mysql_fetch_* hentes fra bufferen.
>
> mysql_use_result(): Forbindelsen initieres, men data hentes _først_ ved
> kald til mysql_fetch_*
>
> Dit eksempel vil således ikke give den nævnte tidsbesparelse, og _aldrig_
> af de årsager, som du anfører.
>
> HA!

Det her er ikke ovre endnu... muhahahaha...

Når jeg får noget mere diskplads fri, så vil jeg prøve det!!

--
Regards, Christian Iversen [FIDUSO]
Flawless.Dk: [http://domains.flawless.dk]
Do you have a (broken?) IBM75GXP Drive?
Please go to [http://ibm.flawless.dk]

---

In article <9h7e4u$13sr$1@news.cybercity.dk>, "Christian Iversen"
<iversen@it.dk> wrote:

> Næ hov!
>
> Manualen siger:
>
> "This reads the result of a query directly from the server without
> storing it in a temporary table or local buffer, ..."
>
> Der kan altså *ikke* være tale om at resultatet er allokeret
>
> Der siges også:
>
> "The client will only allocate memory for the current row ..."

Tillad mig at præcisere en smule: Når jeg taler om at allokere
resultatet, referer jeg til den proces der foregår internt i MySQLs
søgekerne -- altså i mysqld

Man kan under ingen omstændigheder begynde at hente rækker førend hele
resultatet er klargjort i MySQL _serveren_.

De kommentarer du har sakset handler om buffering og allokering i MySQLs
_C-klient_, og der er vi slet ikke uenige.

For at vende tilbage til dit eksempel:

> Vi har en database (DB), hvor vi ønsker at køre en bestemt query (Q). Dette
> gøres på 10 sekunder, da DB er stor.

vil der ikke være forskel på mysql_use_result() og mysql_store_result(),
da queryen sendes af mysql_real_query(), der returnerer en cursor til det
resultatsæt som MySQL-serveren har allokeret / klargjort.

De to forskellige kommandoer handler blot om to forskellige måder at tilgå resultatet på MySQL
serveren fra klienten. Husk at alle de funktioner vi kalder bliver udført
på _klienten_.

> men jeg kunne godt tænke mig at vide hvordan DU kan være så skråsikker?
>

Jeg er ikke skråsikker. Jeg siger bare at det er sådan det nødvendigvis
må forholde sig

/A
--
aj@php.net
Nu med transport til Midtfynsfestival -- www.midtfyn.com

---

> > Næ hov!
> >
> > Manualen siger:
> >
> > "This reads the result of a query directly from the server without
> > storing it in a temporary table or local buffer, ..."
> >
> > Der kan altså *ikke* være tale om at resultatet er allokeret
> >
> > Der siges også:
> >
> > "The client will only allocate memory for the current row ..."
>
> Tillad mig at præcisere en smule: Når jeg taler om at allokere
> resultatet, referer jeg til den proces der foregår internt i MySQLs
> søgekerne -- altså i mysqld

Nå, på dén måde!

> Man kan under ingen omstændigheder begynde at hente rækker førend hele
> resultatet er klargjort i MySQL _serveren_.

Ok.

> De kommentarer du har sakset handler om buffering og allokering i MySQLs
> _C-klient_, og der er vi slet ikke uenige.

Godt. Jeg tror faktisk vi er helt enige...

Men alligevel, hvis man nu laver en stor søgning, hvor noget af tiden går
med buffering, så vil man spare tid. Dét var vist idéen

> For at vende tilbage til dit eksempel:
>
> > Vi har en database (DB), hvor vi ønsker at køre en bestemt query (Q).
Dette
> > gøres på 10 sekunder, da DB er stor.
>
> vil der ikke være forskel på mysql_use_result() og mysql_store_result(),
> da queryen sendes af mysql_real_query(), der returnerer en cursor til det
> resultatsæt som MySQL-serveren har allokeret / klargjort.

Næ, hov. Der kunne godt være en forskel. Det tager jo også tid at lave en
buffer
af et stort dataset.

> De to forskellige kommandoer handler blot om to forskellige måder at
tilgå resultatet på MySQL
> serveren fra klienten. Husk at alle de funktioner vi kalder bliver udført
> på _klienten_.

Hov, hvad mener du? Der må da også blive udført noget på serveren...
ellers sker der jo ingen ting!

> > men jeg kunne godt tænke mig at vide hvordan DU kan være så skråsikker?
> >
>
> Jeg er ikke skråsikker. Jeg siger bare at det er sådan det nødvendigvis
> må forholde sig

Men det er du meget sikker på!

Men jeg tror nu vi er enige, jeg troede ikke du mente mysqld.

--
Regards, Christian Iversen [FIDUSO]
Flawless.Dk: [http://domains.flawless.dk]
Do you have a (broken?) IBM75GXP Drive?
Please go to [http://ibm.flawless.dk]

---

Just as I expected, Christian Iversen came up with this:

>Men alligevel, hvis man nu laver en stor søgning, hvor noget af tiden går
>med buffering, så vil man spare tid. Dét var vist idéen

Nej, det vil tage den samme tid, den der sidder i den anden ende med sin
browser vil bare se nogen resultater noget tidligere!

Niels
--
http://www.niller.f2s.com/ - niLLer's pages, that's my software
http://g4s.dnsq.org/ - when I'm online
g4s ad post dot ocm - new email! (note: it's .com !)
ICQ#: 50187323

---

> >Men alligevel, hvis man nu laver en stor søgning, hvor noget af tiden går
> >med buffering, så vil man spare tid. Dét var vist idéen
>
> Nej, det vil tage den samme tid, den der sidder i den anden ende med sin
> browser vil bare se nogen resultater noget tidligere!


Hvis brugeren ser resultatet i sin browser tidligere, og det tager lige
lang tid at overføre resultatet, hvordan kan man så IKKE spare tid?

--
Regards, Christian Iversen [FIDUSO]
Flawless.Dk: [http://domains.flawless.dk]
Do you have a (broken?) IBM75GXP Drive?
Please go to [http://ibm.flawless.dk]

---

On Sun, 24 Jun 2001 20:19:09 +0200, "Jonas Delfs"
<jonas@nospam.delfs.dk> wrote:

>> - man er afskåret fra at bruge mysql_num_rows()
>Ja, på lige præcist dette query, hvori han jo HAR defineret hvor mange
>resultater han ønsker retur.

Nej, han sætter en max-limit (på 10 artikler). Det er jo ingen garant
for at der rent faktisk i første omgang _er_ 10 artikler i databasen.

Det vil ikke være noget problem i normal drift. Men det kan være ret
grimt at se på under opstarten, hvor der fx er 6 blanke felter uden
overskrifter eller lignende i. Man kan selvfølgelig lade den del at
serverside-koden checke, om der returneres noget, der skal printes,
men det virker som om, man i så fald vil bruge ressourcer på at
kompensere for at man i første omgang valgte en unbuffered query.


--
- Pede
Professionel nørd

---

"Peter Brodersen" <professionel@nerd.dk> skrev i en meddelelse
news:7j4djtk25fcsl67kkohhqb9lh38s8fd5tp@news.worldonline.dk...

> >> - man er afskåret fra at bruge mysql_num_rows()
> >Ja, på lige præcist dette query, hvori han jo HAR defineret hvor mange
> >resultater han ønsker retur.
>
> Nej, han sætter en max-limit (på 10 artikler). Det er jo ingen garant
> for at der rent faktisk i første omgang _er_ 10 artikler i databasen.

Jeg håbede at der ikke ville være nogen der tænkte på det! :)

> Det vil ikke være noget problem i normal drift. Men det kan være ret
> grimt at se på under opstarten, hvor der fx er 6 blanke felter uden
> overskrifter eller lignende i.

Det er så de færreste der vil gøre det på den måde. De fleste vil da i en
while-løkke spytte nogle tabel-rækker ud.

> Man kan selvfølgelig lade den del at
> serverside-koden checke, om der returneres noget, der skal printes,
> men det virker som om, man i så fald vil bruge ressourcer på at
> kompensere for at man i første omgang valgte en unbuffered query.

.... og gør man som flest gør, har man ikke det problem.

_Igen_ - jeg har aldrig anbefalet mysql_unbuffered_query() til dette...

--
Mvh. Jonas Delfs, http://delfs.dk
e72bd3e51a7937c87d28b85d677a97b2

---

On Mon, 25 Jun 2001 13:36:40 +0200, "Jonas Delfs"
<jonas@nospam.delfs.dk> wrote:

>> Det vil ikke være noget problem i normal drift. Men det kan være ret
>> grimt at se på under opstarten, hvor der fx er 6 blanke felter uden
>> overskrifter eller lignende i.
>Det er så de færreste der vil gøre det på den måde. De fleste vil da i en
>while-løkke spytte nogle tabel-rækker ud.

Tjah, det forhindrer stadigvæk ikke folk i at have en overskrift før
while-løkken, fx med overskriften "Seneste 10 nyheder" (hvorefter fx 4
overskrifter følger).

Jeg er nok meget pedantisk hvad det angår. Jeg er også ret konsekvent
med at lave checks for om et navneord skal bruges ental eller flertal
for at undgå output i stil med "Du har 1 breve liggende".


--
- Pede
Professionel nørd

---

"Jesper L Hansen" <lismoes@mail.dk> wrote in message
news:kr2cjtk597r7096j8jlh1ec13q530s0h59@4ax.com...
> Hvilken funktion kan jeg bruge til at trække fx de 10 nyeste (efter
> dato) indlæg i en MySql db ?

$resultat = mysql_query("select * from tabel order by tid desc limit 0,
10");

---

"Thor Dreier" <news@cheater.dk> skrev i en meddelelse
news:d9oZ6.2363$MT.290325@news000.worldonline.dk...

> > Hvilken funktion kan jeg bruge til at trække fx de 10 nyeste (efter
> > dato) indlæg i en MySql db ?
>
> $resultat = mysql_query("select * from tabel order by tid desc limit 0,
> 10");

Det kan klart anbefales at skrive klausuler og andre SQL-ting i uppercase
(med stort) - det letter adskillelsen af klausuler, tabelnavne, feltnavne
m.m.
.... men det er vel bare en smagssag ...

SELECT * FROM tabel ORDER BY tid DESC LIMIT 0,10

--
Mvh. Jonas Delfs, http://delfs.dk
e72bd3e51a7937c87d28b85d677a97b2

---

In article <9h53ej$g0s$1@sunsite.dk>, "Jonas Delfs"
<jonas@nospam.delfs.dk> wrote:

> Det kan klart anbefales at skrive klausuler og andre SQL-ting i
> uppercase (med stort) - det letter adskillelsen af klausuler,
> tabelnavne, feltnavne m.m.
> ... men det er vel bare en smagssag ...

Ligesom det er gavnligt at dele sin forespørgsel op på flere forskellige
linjer, ala:

   SELECT *
   FROM tabel
   ORDER BY tid DESC
   LIMIT 0,10

/A
--
Nu med transport til Midtfynsfestival -- www.midtfyn.com

---

"Anders Johannsen" <anders@ignition.dk> skrev i en meddelelse
news:20010624.183714.968338082.484@ignition.dk...

> > Det kan klart anbefales at skrive klausuler og andre SQL-ting i
> > uppercase (med stort) - det letter adskillelsen af klausuler,
> > tabelnavne, feltnavne m.m.
> > ... men det er vel bare en smagssag ...
>
> Ligesom det er gavnligt at dele sin forespørgsel op på flere forskellige
> linjer, ala:
>
> SELECT *
> FROM tabel
> ORDER BY tid DESC
> LIMIT 0,10

Korrekt.

--
Mvh. Jonas Delfs, http://delfs.dk
e72bd3e51a7937c87d28b85d677a97b2

---

In article <9h56sa$cuf$1@sunsite.dk>, "Jonas Delfs"
<jonas@nospam.delfs.dk> wrote:

>> SELECT *
>> FROM tabel
>> ORDER BY tid DESC
>> LIMIT 0,10
>
> Korrekt.

Ja ?

/A
--
Nu med transport til Midtfynsfestival -- www.midtfyn.com

---

"Anders Johannsen" <anders@ignition.dk> skrev i en meddelelse
news:20010624.195615.707900973.484@ignition.dk...

> >> SELECT *
> >> FROM tabel
> >> ORDER BY tid DESC
> >> LIMIT 0,10
> >
> > Korrekt.
>
> Ja ?

Jeg giver dig bare ret - er det nu også ulovligt?

--
Mvh. Jonas Delfs, http://delfs.dk
e72bd3e51a7937c87d28b85d677a97b2

---

"Jonas Delfs" <jonas@nospam.delfs.dk> wrote in message
news:9h53ej$g0s$1@sunsite.dk...
> Det kan klart anbefales at skrive klausuler og andre SQL-ting i uppercase
> (med stort) - det letter adskillelsen af klausuler, tabelnavne, feltnavne
> m.m.
> ... men det er vel bare en smagssag ...

Jeg ved det. Det er bare en dårlig vane fra min side af.
Det kræver jo at man bevæger fingeren hele vejen over på capslock, og det
kan faktisk være ret hårdt.

---

"Thor Dreier" <news@cheater.dk> skrev i en meddelelse
news:K_oZ6.1915$lf5.334067@news010.worldonline.dk...

> > Det kan klart anbefales at skrive klausuler og andre SQL-ting i
uppercase
> > (med stort) - det letter adskillelsen af klausuler, tabelnavne,
feltnavne
> > m.m.
> > ... men det er vel bare en smagssag ...
>
> Jeg ved det. Det er bare en dårlig vane fra min side af.
> Det kræver jo at man bevæger fingeren hele vejen over på capslock, og det
> kan faktisk være ret hårdt.


Dog kan shift også gøre det :)

--
Mvh. Jonas Delfs, http://delfs.dk
e72bd3e51a7937c87d28b85d677a97b2

---

Tak alle for svarene - nu vil jeg prøve og bikse det sammen

Med venlig hilsen
Jesper L Hansen

---

I en mySQL database har jeg en tabel obs som indeholder to felter, nr
(integer) og besked (string). Tabellen kunne f.eks. se sådan ud:

nr besked
1 "xxx1"
5 "xxx2"
11 "xxx3"
1213 "xxx4"

dvs. at de er sorteret efter nr. Hvordan får jeg nu fat i den sidste
record i databasen, når jeg ikke altid ved hvilken værdi nr. har?

Jeg gætter på at der findes en funktion som kan oplyse "last-record" i
en table, men hvad er syntaksen og har I evt. kendskab til nogle gode
websites med lettilgængelig viden om SQL syntaks ?.

Hilsen Lars

---

Lars Lindgren <tegnestue@worldonline.dk> wrote:

> I en mySQL database har jeg en tabel obs som indeholder to felter, nr
> (integer) og besked (string). Tabellen kunne f.eks. se sådan ud:
>
> nr besked
> 1 "xxx1"
> 5 "xxx2"
> 11 "xxx3"
> 1213 "xxx4"
>
> dvs. at de er sorteret efter nr. Hvordan får jeg nu fat i den sidste
> record i databasen, når jeg ikke altid ved hvilken værdi nr. har?

SELECT besked FROM <tabel> ORDER BY nr DESC LIMIT 1

--
Christian Jørgensen | "Ford, you're turning into a penguin"
http://www.razor.dk | "Stop it"