xDSL.at

von **xbs** » Fr 23 Aug, 2002 15:12

tag.

ich befasse mich mit MySQL noch nicht so lange und bin halt auf ein problem gestoßen...

1///

wenn ich mit auto_increment felder hochzähle, hat das den nachteil, dass sie die automatisch generierten nummern dann fest sind, ich will aber, dass sie virtuell variabel bleiben... als beispiel.. ich habe folgende zeilen und jeweils in der ersten spalte befindet sich die auto_increment generierte zahl:

1
2
3

so.. nun lösche ich zeile 2 und es bleibt eine lücke.. die nächste zeile bekommt nun die id 4...

ICH möchte aber, dass nach dem löschen von 2; die zeile mit id 3 auf zwei nachrutscht.. damit keine lücke entsteht...

ich habe mal so gehört, dass man sowas mit nem Hash lösen könnte, aber ne genaue anleitung hab ich nich bekommen... jemand je lösung?

2///

ein ähnliches Problem, liegt aber nur indrekt an auto_increment:
ich habe wieder die spalten 1,2,3 .. nun lösche ich drei und somit wäre id 3 für auto_increment wieder verfügbar... trotzdem wird 3 übersprungen und bei 4 weiter gemacht.. ich weis. das die zeile zwar als gelöscht markiert ist, aber noch vorhanden ist und deswegen dieses problem auftritt... in dier MySQL configuration kann ich das auch wunderbar ausstellen, nur habe ich die möglichkeit auf einem webserver nicht.. wie bekomme ich also mit nem SQL befehle die zeile gleich gelöscht, ohne dass sie vorerst nur markiert ist?

danneschön im vorraus, xbs

von **mad** » Fr 23 Aug, 2002 15:55

<HTML>hallo,

ich wuerd sagen du hast den sinn hinter auto_incement bzw. sequences bei
relationalen datenbanken irgendwie nicht ganz verstanden ..

> ICH möchte aber, dass nach dem löschen von 2; die zeile mit id 3 auf zwei nachrutscht.. damit keine lücke entsteht...

sequences werden dazu verwenden um einzelnen objekte (datenbankeintraegen)
_eindeutige_ id's (primaere tabellenschluessel) zuzuweisen .. nicht um sie durchzuzaehlen ..

wenn sich diese id's durch entfernen von anderen
eintraegen jetzt ploetzlich veraendern, dann wuerden diese id's ja voellig
wertlos sein .. alle referenzen aus anderen tabellen auf diese id's wuerden
ja plotzlich auf die falschen eintraege zeigen ..

aber ok .. selbst wenn du das machen willst .. und es ginge ..
ueberleg mal .. du hast einen table mit 1million eintraege .. jetzt loescht du den 3.
eintrag .. hurra, dann muesste die db plötzlich 999997 felder updaten ...
frag wie effizient das ist :-)

> ich habe wieder die spalten 1,2,3 .. nun lösche ich drei und somit wäre id 3 für auto_increment wieder verfügbar... trotzdem wird 3 übersprungen und bei 4

das hat was mit "race-conditions" zutun .. um sicher zustellen, dass diese,
durch sequences generierten _eindeutigen_ id's wirklich _eindeutig_ sind, werden
diese einfach stur sequenziell hochgezaehlt. damit ist sichergestellt dass zwei
parallel auf die db zugreifende client-aplikationen immer auch zwei verschiedene (=eindeutige) id's erhalten. eine integer zahl hochzuzaehlen und zu returnieren ist
nun mal eine atomare funktion (daher auch keine raceconditions).

... wenn es so waere wie du es gern haettest ..
dann muesste die db eine liste mitfuehren von wegen welche eintraege wieder
frei sind und jedesmal wenn du ein neues insert machst in dieser liste schaun
ob nicht eine zuvor geloeschtee id vorhanden waere etc ...
bei einer mio eintraege, hunderttausend geloschte entraege, 100te inserts/deletes
pro sekunde ... sicher sehr effizient und sinnvoll das ganze .. NOT.

naja ..
hoffentlich hab ich dich jez nicht ganz verwirrt mit dem blafasel .. :-)

dein problem wirst allso fast applikationstechnisch (mit all den damit verbundenen
nachteilen: zb. raceconditions!) loesen muessen.

mad.
</HTML>

xDSL.at

Fragen zu: auto_increment ; hash; löschen

Fragen zu: auto_increment ; hash; löschen

RE: Fragen zu: auto_increment ; hash; löschen

Wer ist online?