---

I en MySQL 4.1 database vil jeg gerne kunne gøre flg:
(version 4.1 har understøttelse for subselects)

Hvordan opdaterer jeg senest indsatte række i en tabel med nye værdier
uden at bruge LAST_INSERT_ID() ?

Jeg ville gerne kunne gøre noget lignende:

UPDATE t1 SET c1='1' WHERE id=(
         SELECT id FROM t1 ORDER BY id DESC LIMIT 1)

Man kunne også forestille sig noget lignende nedenstående, men det
virker heller ikke:

UPDATE t1 SET c1='1' WHERE id=max(id)

Er der nogen, der har et løsningsforslag?

--
Venlig hilsen
Thorbjørn

P.S. Fjern INGENSPAM fra min email

---

"Thorbjørn Højgaard Olesen" <tho@INGENSPAMperson.dk> wrote in message
news:bad2er$ksj$1@sunsite.dk...
> I en MySQL 4.1 database vil jeg gerne kunne gøre flg:
> (version 4.1 har understøttelse for subselects)
>
> Hvordan opdaterer jeg senest indsatte række i en tabel med nye værdier
> uden at bruge LAST_INSERT_ID() ?
¨
Hvorfor ikke LAST_INSERT_ID()?


> Jeg ville gerne kunne gøre noget lignende:
>
> UPDATE t1 SET c1='1' WHERE id=(
> SELECT id FROM t1 ORDER BY id DESC LIMIT 1)

Er du sikker på du ikke løber ind i det klassiske begynderproblem at tro, at
det ID der er højest når man udfører sin SELECT også må være det ID man
*lige* har sat ind?

Mvh
Jimmy

---

Jimmy wrote:
>>Hvordan opdaterer jeg senest indsatte række i en tabel med nye værdier
>>uden at bruge LAST_INSERT_ID() ?
> ¨
> Hvorfor ikke LAST_INSERT_ID()?

Fordi der skal indsættes andre rækker i andre tabeller inden jeg kan
opdatere den ønskede række.

>>Jeg ville gerne kunne gøre noget lignende:
>>
>>UPDATE t1 SET c1='1' WHERE id=(
>>SELECT id FROM t1 ORDER BY id DESC LIMIT 1)
>
> Er du sikker på du ikke løber ind i det klassiske begynderproblem at
> tro, at det ID der er højest når man udfører sin SELECT også må være
> det ID man *lige* har sat ind?

Det tror jeg ikke?!?
Hvis man bruger auto_increment, så vil den nyeste række da altid have
den største id, også selvom der er blevet slettet en eller flere rækker
med lavere id...

MVH Thorbjørn

---

"Thorbjørn Højgaard Olesen" <tho@INGENSPAMperson.dk> wrote in message
news:bad7ao$s32$1@sunsite.dk...
> Jimmy wrote:
> >>Hvordan opdaterer jeg senest indsatte række i en tabel med nye værdier
> >>uden at bruge LAST_INSERT_ID() ?
> > ¨
> > Hvorfor ikke LAST_INSERT_ID()?
>
> Fordi der skal indsættes andre rækker i andre tabeller inden jeg kan
> opdatere den ønskede række.

Så ville jeg nok løse det ved at hente det aktuelle ID vha. LAST_INSERT_ID()
og gemme det i en variabel.

Dog kunne jeg forestille mig, at man godt kan sætte en linie ind i tabel 1,
derefter x linier i tabel 2 og 3 og derefter hente det senest indsatte ID
fra tabel 1.


> > Er du sikker på du ikke løber ind i det klassiske begynderproblem at
> > tro, at det ID der er højest når man udfører sin SELECT også må være
> > det ID man *lige* har sat ind?
>
> Det tror jeg ikke?!?
> Hvis man bruger auto_increment, så vil den nyeste række da altid have
> den største id, også selvom der er blevet slettet en eller flere rækker
> med lavere id...


Ja, men i et multi-user miljø, f.eks. en hjemmeside, er der mulighed for at
andre end dig kan indsætte en række og dermed et ID.

Selvom det ikke er multi-user miljø mener jeg, at det er dårlig kode at
anvende MAX() til at finde det seneste ID, når der er oprettet funktioner
der gør præcis det ønskede.

Hvad mener I andre MySQL-brugere om MAX() vs. LAST_INSERT_ID() til at finde
det *seneste* ID, man *selv* har indsat?

Mvh
Jimmy

---

"Jimmy" <nyhedsgruppe@get2net.dk> skrev i en meddelelse
news:Sjqya.637$Uw3.480@news.get2net.dk...
> Ja, men i et multi-user miljø, f.eks. en hjemmeside, er der mulighed for
at
>andre end dig kan indsætte en række og dermed et ID.

Dette kan undgås hvis man benytter en lås på tabellen.

> Selvom det ikke er multi-user miljø mener jeg, at det er dårlig kode at
> anvende MAX() til at finde det seneste ID, når der er oprettet funktioner
> der gør præcis det ønskede.
>
> Hvad mener I andre MySQL-brugere om MAX() vs. LAST_INSERT_ID() til at
finde
> det *seneste* ID, man *selv* har indsat?

Hvis man var sikker på at andre ikke ændrede på tabellen imens, så kunne man
jo spare en
SELECT ved at bruge MAX(), hvis man som Thorbjørn har en række andre INSERTS
ind i mellem.
Problemmet er bare at man ikke kan have MAX i en update i MySQL.

/rw

---

"Rico Wind" <rw@INGEN-SPAM.rico-wind.dk> wrote in message
news:baf3oa$mva$1@sunsite.dk...
>
> "Jimmy" <nyhedsgruppe@get2net.dk> skrev i en meddelelse
> news:Sjqya.637$Uw3.480@news.get2net.dk...
> > Ja, men i et multi-user miljø, f.eks. en hjemmeside, er der mulighed for
> at
> >andre end dig kan indsætte en række og dermed et ID.
>
> Dette kan undgås hvis man benytter en lås på tabellen.

Ja, men det er jo ikke så hensigtsmæssigt, hvis man kan undgå det.


> > Selvom det ikke er multi-user miljø mener jeg, at det er dårlig kode at
> > anvende MAX() til at finde det seneste ID, når der er oprettet
funktioner
> > der gør præcis det ønskede.
> >
> > Hvad mener I andre MySQL-brugere om MAX() vs. LAST_INSERT_ID() til at
> finde
> > det *seneste* ID, man *selv* har indsat?
>
> Hvis man var sikker på at andre ikke ændrede på tabellen imens, så kunne
man
> jo spare en
> SELECT ved at bruge MAX()

Nej, han skal stadig SELECT MAX(ID).


, hvis man som Thorbjørn har en række andre INSERTS
> ind i mellem.
> Problemmet er bare at man ikke kan have MAX i en update i MySQL.

Han vil anvende det i en sub-select.

Mvh
Jimmy

---

"Jimmy" <nyhedsgruppe@get2net.dk> skrev i en meddelelse
news:iaOya.3147$9b.947@news.get2net.dk...
> >
> > Hvis man var sikker på at andre ikke ændrede på tabellen imens, så kunne
> man
> > jo spare en
> > SELECT ved at bruge MAX()
>
> Nej, han skal stadig SELECT MAX(ID).
>
>
> , hvis man som Thorbjørn har en række andre INSERTS
> > ind i mellem.
> > Problemmet er bare at man ikke kan have MAX i en update i MySQL.
>
> Han vil anvende det i en sub-select.

Kig lige på Thorbjørns første indlæg igen!. Han ville ikke bruge MAX i en
sub select, men i en update, men det kan man ikke (Pointen er at hvis han
kunne, ville han spare en select)!
Og han kan heller ikke havde en subselect hvor tabellen fra UPDATE optræder
i FROM i subselecten (fordi han bruger MySQL).
Nu kan du selvfølgelig sige at hans subselect gør det samme som MAX, men
problemmet for ham er det samme.

/rw

---

"Jimmy" <nyhedsgruppe@get2net.dk> wrote in message
news:Sjqya.637$Uw3.480@news.get2net.dk...
>

> Ja, men i et multi-user miljø, f.eks. en hjemmeside, er der mulighed for
at
> andre end dig kan indsætte en række og dermed et ID.
>
> Selvom det ikke er multi-user miljø mener jeg, at det er dårlig kode at
> anvende MAX() til at finde det seneste ID, når der er oprettet funktioner
> der gør præcis det ønskede.

Det er faktisk ret interessant at se på performance-test, når vi snakker
LAST_INSERT_ID og MAX(ID)

1000 INSERTs, 1000 SELECTs på hver af dem - Intet index.

LAST_INSERT_ID() tog 20 sekunder
MAX(ID) tager 4

Tallene viser tydeligt, at MAX(ID) performer bedre, men den har naturligvis
stadig de tidligere nævnte ulemper, hvorfor jeg fortsat anbefaler at man
anvender LAST_INSERT_ID, da den jo er bygget til formålet.

Mvh
Jimmy

---

"Jimmy" <nyhedsgruppe@get2net.dk> wrote in message
news:PfSya.3204$Fb2.3152@news.get2net.dk...
>
> "Jimmy" <nyhedsgruppe@get2net.dk> wrote in message
> news:Sjqya.637$Uw3.480@news.get2net.dk...
> >
>
> > Ja, men i et multi-user miljø, f.eks. en hjemmeside, er der mulighed for
> at
> > andre end dig kan indsætte en række og dermed et ID.
> >
> > Selvom det ikke er multi-user miljø mener jeg, at det er dårlig kode at
> > anvende MAX() til at finde det seneste ID, når der er oprettet
funktioner
> > der gør præcis det ønskede.
>
> Det er faktisk ret interessant at se på performance-test, når vi snakker
> LAST_INSERT_ID og MAX(ID)
>
> 1000 INSERTs, 1000 SELECTs på hver af dem - Intet index.
>
> LAST_INSERT_ID() tog 20 sekunder
> MAX(ID) tager 4


Nu er der lavet flere tests af Morten, som undertiden skriver herinde, og
jeg.

Testen blev udført vha. 100000 INSERTs og 100000 SELECTS.


SELECT MAX(ID) FROM <table> -> 70 sekunder
SELECT LAST_INSERT_ID() FROM <table> LIMIT 1 -> 70 sekunder
SELECT LAST_INSERT_ID() -> 58 sekunder

Der var mindre variationer i sekunderne, men det lå næstene altid i nærheden
af ovenstående.

Vælger man at angive FROM <table> i sin SELECT er det *vigtigt* at huske
LIMIT 1.
MySQL forbereder sig dog stadig på at løbe alle rækker igennem, men LIMIT 1
gør at den stopper når den har afviklet en runde.

Undlader man LIMIT 1 løb den i vores tilfælde 755000 rækker, hvilket krævede
max CPU af både klient og server.


Det ses nu klart, at LAST_INSERT_ID() ikke blot er den per definition
*rigtige* løsning, men også den, der performer bedst.

Mvh
Jimmy