ID med databaser

[kaffenils]

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

 

Hjelper lite å bruke transaksjoner så lenge du ikke plasserer en exclusive locks på de riktige indexene og de riktige delene av indexene, noe de aller færreste tenker på eller vet hvordan skal gjøres. Jeg vet at du bare får en masse problemer, spesielt med concurrency, hvis en absolutt skal lage "hent-min-autonummer-verdi-ved-insert" funksjonen selv.

 

Som dere sikkert forstår så synes begge måtene å finne hvilken autonummer-verdi som nettopp ble satt inn er ubruklige. Bruk heller de innebygde funskjonene i som finnes for de forskjellige databasesystemene for å hente ut auto_number/identity-verdier ved insert.

 

Edit: Det samme gjelder selvfølgelig hvis en skal prøve å lage sin egen autonummer-funksjon. Det er selvfølgelig mulig, men du skal vite hva du holder på med. Både "max" og "top 1 desc" mot tabellen som inneholder dataene er nærmest ubrukelige hvis en ikke vil ofre alt som har med concurrency å gjøre.

Endret 14. september 2007 av kaffenils

[roac]

Som dere sikkert forstår så synes begge måtene å finne hvilken autonummer-verdi som nettopp ble satt inn er ubruklige. Bruk heller de innebygde funskjonene i som finnes for de forskjellige databasesystemene for å hente ut auto_number/identity-verdier ved insert.

 

Edit: Det samme gjelder selvfølgelig hvis en skal prøve å lage sin egen autonummer-funksjon. Det er selvfølgelig mulig, men du skal vite hva du holder på med. Både "max" og "top 1 desc" mot tabellen som inneholder dataene er nærmest ubrukelige hvis en ikke vil ofre alt som har med concurrency å gjøre.

9492598[/snapback]

Selvsagt enig med deg her. Jeg ønsket bare å poengtere mulige forskjeller i hvordan de to spørringene det var snakk om fullføres. Når vi først er inne på det, så er det mange som ikke er klar over forskjellen på @@identity og scope_identity, eller for den saks skyld ident_current i SQL Server også, noe som er meget viktig hvis du har triggere.

[kaffenils]

Når vi først er inne på det, så er det mange som ikke er klar over forskjellen på @@identity og scope_identity, eller for den saks skyld ident_current i SQL Server også, noe som er meget viktig hvis du har triggere.

 

Tell me about it!!

I SQL Server 7 så hadde du bare @@IDENTITY. SCOPE_IDENTITY() ble innført i SQL Server 2000.

 

Vårt dok.kontroll system ble "født" i SQL Server 7, og vi måtte selvfølgelig bruke @@IDENTITY.

Etter oppgradering til SQL Server 2000 ble alt skrevet om til SCOPE_IDENTITY(), trodde jeg. Uansett, det fungert, selv med @@IDENTITY, da det ikke var noen triggere som rotet det til der @@IDENTITY hadde gjemt seg bort. Vi satte opp merge replikering i SQL Server 2000 og som du sikkert vet så opprettes det en ins,upd og del trigger for hver tabell. Ingen problemer foreløpig da disse triggerene ikke inserter til tabeller med identitykolonner. Alt fungerte fint i alle år.... helt til.... SQL Server 2005!!

I SQL Server 2005 så har nemlig endel av systemtabellene som brukes til merge replikering fått hver sin identitykolonne. Og enkelte av disse tabellene insertes det selvfølgelig til fra triggerene jeg nevnte, men selvfølgelig er det ikke konsekvent at en trigger inserter til en systemtabell, av og til kjører den kun en update.

Jeg oppdaget heldigvis og fikk rettet feilen på testsytemet før vi gikk live, men det var en vanskelig feil å oppdage det ikke var en feil som oppsto konsekvent.

[blackbrrd]

Tja... Hvis en databasemotor gjør en sort når du vil ha ut den raden med min/max verdi av en kolonne så er det avvikende oppførsel i forhold til det som er normalt. Derav min kommentar...

 

Mao, jeg ser ikke hvorfor max skal være bedre enn order by desc limit 1. Man spør jo etter samme data. At du mener det er opplagt at databasemotoren optimizer max korrekt, men ikke order by limit 1 kommer kanskje mest av at det er det du er vant med å bruke?

 

Jeg sier forresten ikke at noen av valgene er feil, på ingen måte, jeg sier bare at det i utgangspunktet ikke skal spille noen rolle...

[blackbrrd]

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

 

Hjelper lite å bruke transaksjoner så lenge du ikke plasserer en exclusive locks på de riktige indexene og de riktige delene av indexene, noe de aller færreste tenker på eller vet hvordan skal gjøres. Jeg vet at du bare får en masse problemer, spesielt med concurrency, hvis en absolutt skal lage "hent-min-autonummer-verdi-ved-insert" funksjonen selv.

 

Som dere sikkert forstår så synes begge måtene å finne hvilken autonummer-verdi som nettopp ble satt inn er ubruklige. Bruk heller de innebygde funskjonene i som finnes for de forskjellige databasesystemene for å hente ut auto_number/identity-verdier ved insert.

 

Edit: Det samme gjelder selvfølgelig hvis en skal prøve å lage sin egen autonummer-funksjon. Det er selvfølgelig mulig, men du skal vite hva du holder på med. Både "max" og "top 1 desc" mot tabellen som inneholder dataene er nærmest ubrukelige hvis en ikke vil ofre alt som har med concurrency å gjøre.

9492598[/snapback]

 

Kan bare si meg enig i det - når du først tar det opp.

 

Jeg har selv bare brukt order by desc limit 1 opplegget for å hente ut den auto-generete ID-en.

[TheClown]

Fin liten bump her. Har testet scriptet mitt litt og jeg har problemer med ID greia. Noen som veit hvorfor IDen jeg får til slutt er tallet fra databasen og ikke tallet fra databasen + 1?

 

// Get the highest ID from the database
	$idget = "SELECT * FROM link where link_id = (SELECT max(link_id) FROM link)"; $resultt=mysql_query($idget) or die(mysql_error());
	while ($roww=mysql_fetch_assoc($resultt))
	{
		$idd = $roww['link_id'];
	}
	mysql_free_result($resultt);

	// Add one to get a new ID
	$iddd = $idd + 1;