ID med databaser

[TheClown]

Heisann. Jeg har et lite problem. Jeg har et ID system på siden min. Det er gitt en ID til hver bruker:

 

***ID*******NAVN***************
*    1       *     LOL1      *
*    2       *     LOL2      *
*    3       *     LOL3      *
*******************************

 

Alle disse har jeg lagt til ved spøøring i PhpMyAdmin, men nå vil jeg sette opp slik at man kan lage bruker og sånt selv. Det meste klarer jeg selv. Men jeg trenger litt hjelp til å lage ID til en ny bruker. Hvordan henter man ut den siste IDen (eller høyeste) legger til en og skriver det inn i databasen?

 

All hjelp mottas med

[BigJackW]

Det kan gjøre automatisk.

 

ALTER TABLE tabellNavn ADD PRIMARY KEY(id);

ALTER TABLE tabellNavn CHANGE id INT( 11 ) NOT NULL AUTO_INCREMENT;

Endret 27. august 2007 av BigJackW

[TheClown]

Av forskjellige grunner skulle jeg gjerne hatt det som variable. Men takk for rask svar

[Crowly]

For høyeste verdi bruk

 

SELECT max(id) FROM ...

[TheClown]

Crowly har alltid svaret

 

Takk

[TheClown]

Hvordan blir dette lagret? Og hvordan kan jeg bahandle det?

 

På samme måte som alle andre SELECT? I en loop?

[Crowly]

Ja

Hvis du skal hente ut flere felter i sammen med max(id) så må du bruke GROUP BY, og muligens andre group by funksjoner rundt de andre feltene også. Uten GROUP BY så blir det kun returnert en forekomst, da kun en verdi er størst

 

PHP

<?php

// returnerer kun ett resultat

$res=mysql_fetch_assoc(mysql_query("SELECT max(id) FROM tabell"));

echo '<div>'.$res['id'].'</div>';

?>

Endret 4. september 2007 av crowly

[supermodps2]

Hvis du trenger den siste raden men flere kolonner enn id ..kan du bruke

SELECT * FROM tabell ORDER BY id DESC LIMIT 0, 1

[roac]

Hvis du trenger den siste raden men flere kolonner enn id ..kan du bruke

SELECT * FROM tabell ORDER BY id DESC LIMIT 0, 1

9424397[/snapback]

Og hvis du har en databaseserver som støtter det, så vil det sannsynligvis være mer effektivt å kjøre:

SELECT * FROM tabell where ID = (SELECT max(id) FROM tabell)

Siden dette i en del tilfeller vil eliminere en table scan, og ikke minst sortering av hele tabellen (max er streaming aggreagte).

[TheClown]

Nei det eneste jeg ville ha er IDen i en var som jeg kan bruke seinere i scriptet

 

funker

<?php
// returnerer kun ett resultat
$res=mysql_fetch_assoc(mysql_query("SELECT max(id) FROM tabell")); $res['id''] = $idShit;
?>

 

?

[Crowly]

Ja men i eksemplet ditt så overskriver du verdien fra databasen, du kan gjøre slik

PHP

<?php

$id=mysql_fetch_assoc(mysql_query("SELECT max(id) FROM tabell"));

$id=$id['id'];

?>

 

Da vil $id f.eks ha verdien 2

[Manfred]

Ja men i eksemplet ditt så overskriver du verdien fra databasen, du kan gjøre slik

PHP

<?php

$id=mysql_fetch_assoc(mysql_query("SELECT max(id) FROM tabell"));

$id=$id['id'];

?>

 

Da vil $id f.eks ha verdien 2

9425375[/snapback]

å bruke variablen $id to ganger til noe så vidt forskjellig (en hasttable, som er et sql recordset, og så etterpå en integer) er noe av det styggeste jeg har sett.

[Crowly]

Er sikkert ikke en pen måte å kode på, men det fungerer. Kan jo f.eks gjøre det slik, så blir det litt penere

PHP

<?php

$temp=mysql_fetch_assoc(mysql_query("SELECT max(id) FROM tabell"));

$id=$temp['id'];

unset($temp);

?>

[blackbrrd]

Hvis du trenger den siste raden men flere kolonner enn id ..kan du bruke

SELECT * FROM tabell ORDER BY id DESC LIMIT 0, 1

9424397[/snapback]

Og hvis du har en databaseserver som støtter det, så vil det sannsynligvis være mer effektivt å kjøre:

SELECT * FROM tabell where ID = (SELECT max(id) FROM tabell)

Siden dette i en del tilfeller vil eliminere en table scan, og ikke minst sortering av hele tabellen (max er streaming aggreagte).

9424624[/snapback]

 

Hmm, det kommer vel rimelig mye an på hvilken database-engine du bruker?

 

Begge spørringene skal returnere de samme dataene, men hvordan de blir hentet ut er ikke definert... Det logiske her er jo å bruke indeksen på feltet du har max eller order by på, men det er ikke alltid det skjer, avhengig av hvilken måte du bruker og hvilken database (versjon) du bruker.

 

F.eks postgres slet med at max/min funksjonene ikke brukte indekser inntil relativt nylig... Mao vil det med en tidligere versjon av postgres fungere svært dårlig å bruke max funksjonen.

 

Personlig ville jeg foretrukket denne syntaksen:

 

SELECT * FROM tabell ORDER BY id DESC LIMIT 1

 

Litt lite relevant siden det sikkert blir brukt MySql her, men postgres ville latt deg gjøre noe slikt (forutsetter bruk av sequences):

 

INSERT INTO tabell (....) RETURNING id

 

Sikkert ikke noen SQL standard, eller lite implementert, så sikkert en dårlig ide

Endret 13. september 2007 av blackbrrd

[roac]

Begge spørringene skal returnere de samme dataene, men hvordan de blir hentet ut er ikke definert... Det logiske her er jo å bruke indeksen på feltet du har max eller order by på, men det er ikke alltid det skjer, avhengig av hvilken måte du bruker og hvilken database (versjon) du bruker.

9489662[/snapback]

Såklart, og det vil alltid være forskjell på databasemotorer. Det hele kommer an på hvor god query optimizer er, og en god query optimizer vil finne ut at de to er identiske, og vil bruke indeksen. En dårlig query optimizer vil ikke noen av delene.

 

Konseptuelt er de to dog forskjellige. I den ene sier du at du skal ha ut den første raden når dataene er sortert etter ID, hvilket fort vil kunne tvinge databaseserveren til å gjøre en sortering av resultatsettet, hvorpå kun første rad returneres. Med gode algoritmer i blant annet query optimizer kan det elimineres.

 

I den andre ber du om å få ut den raden som tilfredsstiller at IDen er den høyeste IDen i tabellen, og dette skal såvidt jeg vet ikke i noe tilfelle føre til sortering av hele tabellen.

 

For små mengder data vil dette være irrelevant, men for store mengder data vil du kunne få merkbart dårligere ytelse hvis hele tabellen må sorteres, samt at det vil kunne spise store mengder minne.

 

Ut i fra dette mener jeg at det klart er å anbefale å bruke max, såfremt det ikke er en ulempe med dette i databaseserveren og du vet at du får dårligere ytelse ved å bruke denne.

 

Men det er jo noe som heter smak og behag.

[BlueEAGLE]

http://no2.php.net/manual/en/function.mysql-insert-id.php er vel et alternativ, er det ikke?

[Wattengård]

Og så må du huske at hvis det skjer at to stykker registrerer seg ca. samtidig så kan du risikere at i perioden mellom at du tok "MAX(id)" til du lagrer neste rad med id+1, så kan det ha kommet en ny rad der... Da sliter du vel en smule

 

Er det en spesiell grunn til at du ikke kan bruke autogenerert id?

 

-C-

[blackbrrd]

Og så må du huske at hvis det skjer at to stykker registrerer seg ca. samtidig så kan du risikere at i perioden mellom at du tok "MAX(id)" til du lagrer neste rad med id+1, så kan det ha kommet en ny rad der... Da sliter du vel en smule

 

Er det en spesiell grunn til at du ikke kan bruke autogenerert id?

 

-C-

9491532[/snapback]

 

Vel, isåfall bruker du ikke transaksjoner som forhindrer dette og du sitter egentlig bare å venter på data som ikke henger sammen..

[blackbrrd]

Begge spørringene skal returnere de samme dataene, men hvordan de blir hentet ut er ikke definert... Det logiske her er jo å bruke indeksen på feltet du har max eller order by på, men det er ikke alltid det skjer, avhengig av hvilken måte du bruker og hvilken database (versjon) du bruker.

9489662[/snapback]

Såklart, og det vil alltid være forskjell på databasemotorer. Det hele kommer an på hvor god query optimizer er, og en god query optimizer vil finne ut at de to er identiske, og vil bruke indeksen. En dårlig query optimizer vil ikke noen av delene.

 

Konseptuelt er de to dog forskjellige. I den ene sier du at du skal ha ut den første raden når dataene er sortert etter ID, hvilket fort vil kunne tvinge databaseserveren til å gjøre en sortering av resultatsettet, hvorpå kun første rad returneres. Med gode algoritmer i blant annet query optimizer kan det elimineres.

 

I den andre ber du om å få ut den raden som tilfredsstiller at IDen er den høyeste IDen i tabellen, og dette skal såvidt jeg vet ikke i noe tilfelle føre til sortering av hele tabellen.

 

For små mengder data vil dette være irrelevant, men for store mengder data vil du kunne få merkbart dårligere ytelse hvis hele tabellen må sorteres, samt at det vil kunne spise store mengder minne.

 

Ut i fra dette mener jeg at det klart er å anbefale å bruke max, såfremt det ikke er en ulempe med dette i databaseserveren og du vet at du får dårligere ytelse ved å bruke denne.

 

Men det er jo noe som heter smak og behag.

9491023[/snapback]

 

Jeg kom akkurat med ett eksempel på at max funksjonen kunne være tregere enn order by metoden... dvs at max funksjonen endte med en sequential scan av hele tabellen... men det fikk du kanskje ikke med deg?

[roac]

Jeg kom akkurat med ett eksempel på at max funksjonen kunne være tregere enn order by metoden... dvs at max funksjonen endte med en sequential scan av hele tabellen... men det fikk du kanskje ikke med deg?

9491640[/snapback]

Jo da, hvis du hadde tatt deg tid til å lese svaret mitt så hadde du klart sett at jeg gjorde det, og jeg kommer også med et forbehold. Det er overhodet ikke noen problemer forbundet med å avvike fra en "best practice" når det er en reell grunn til det, men slik jeg ser det er dette et klar avvik fra hva som er vanlig oppførsel fra en databaseserver, og da å anbefale noe basert på et "avvikende oppførsel" fra en annen databasemotor blir for meg helt feil.