SQL Tabelle neu indizieren

[Extinction]

Hallo!
Ich hab ein eigentlich simples Problem: Ich habe eine Tabelle, die einen "INT primary key auto_increment" hat. Nun füge ich fleißig Datensätze ein, sagen wir 1...10, und lösche dann mittendrinn welche, sagen wir mal 5 und 8.
Wie bekomme ich es nun hin, dass die Höheren Indizes jetzt nach unten aufrücken? Das also der alte Index 6 auf die 5 "rutscht" usw.
Das ganze sollte natürlich auch tabellenübergreifend (mit inner join auf den primary key) gehen.
Irgendwie fällt mir da kein gescheiter Lösungsansatz ein, außer "etwas auf Händen und Füßen" in C++...
Währe nett, wenn mir da jemand weiterhelfen könnte.

 

[LX]

Der Trick ist... es zu lassen. IDs sind in aller Regel dazu gedacht, eindeutig zu sein, und dass du auch in zwei Wochen noch denselben Datensatz unter der gleichen ID hast. So kannst du dich auch drauf verlassen, dass deine Datensätze auch über mehrere Tabellen hinweg konsistent bleiben. Wenn du an irgendeiner Stelle fortlaufend nummerierte Datensätze brauchst, dann machst du was falsch

Einträge bei der Ausgabe einfach durchnummerieren ist ja kein Problem, das muss aber nicht mit IDs in der Datenbank korrespondieren.

 

[Vyger]

Ich glaube die Frage war nicht wie man die Primarykeys verwirrt, sondern wie man Indexe neu bildet.

http://msdn.microsoft.com/de-de/library/ms188388.aspx

Falls es nicht darum ging, dann solltest Du ernsthaft über indexe nachdenken.
Sie machen deine Queries schneller, wenn sie richtig eingerichtet sind.

http://msdn.microsoft.com/de-de/library/ms188783.aspx

//Edit: Vielleicht löst auch eine zusätzliche "Spalte" dein offensichtliches debakel.
Eine ID, die Du vergeben kannst wie Du willst.
Die dann kein Primärschlüssel ist.
Diese IDs kannst Du dann neu ordnen, wenn ein Datensatz entfernt wird(onDelete).

 

[Extinction]

IDs sind in aller Regel dazu gedacht, eindeutig zu sein, und dass du auch in zwei Wochen noch denselben Datensatz unter der gleichen ID hast.

Eindeutig bleiben sie ja. Die ID's sollen ja nur aufrücken, wo Lücken entstanden sind.
Zweiteres ist nicht unbedingt wichtig. Wenn man Tabellen join'ed sollten die die anderen Tabellen natürlich dementsprechend geändert werden. Und wenn man z.B. den Inhalt einer Seite über die id erreicht (z.B. forum.php?ThreadID=40697) dann macht man das halt über einen anderen Identifier, wie Vyger schon sagte.

@Vyger
MSSQL... Oo
Ich arbeite mit SQLite3 und MySQL, aber syntax dürfte weitgehend gleich sein. Muss mich noch erst mit der Syntax auseinandersetzen, aber ich denke, das ist, was ich gesucht habe.

 

[Vyger]

Wenn der Primärschlüssel auch dein Eineindeutiger Index der Tabelle ist geht das nicht. Diese darf sich _nie_ wiederholen.
Wenn nicht kannst du wie gesagt ein ganz normales update machen.

 

[metax.]

Hallo,
es bringt normalerweise effektiv keinen Vorteil, die IDs aufrücken zu lassen, wenn eine zwischendrin gelöscht wird. Wozu soll das denn gut sein?
Es hat im Gegenteil den Nachteil, dass Datenzusammenhänge vorloren gehen oder sich verschieben, wenn du die ID nachträglich änderst.

Beispiel: Ich schaue mir z.B. in einem Katalog den Datensatz #1033 an. Weil er mir gefällt, speichere ich den Link oder merke mir die Nummer.
Jetzt löschst du den Datensatz #765. Schon ist mein Link und meine gemerkte ID ungültig, falls die anderen IDs nachrücken -> schlechte Idee.

Naja, wenn du doch unbedingt die IDs aufrücken musst, musst du das wahrscheinlich per Hand oder mit einem Programm machen. Zumindest bei MySQL ist mir kein Mechanismus bekannt, der das automatisch kann. Trigger kann MySQL afaik nicht.
Aber es würde dir in diesem Fall schon was bringen, wenn du Verbindungen auf dieses ID-Feld in deiner Datenbank als Fremdschlüssel (Foreign Keys) definierst. Fremdschlüssel lassen sich nämlich so einstellen, dass sie automatisch ihren Wert ändern, wenn die Ursprungszelle, auf die sie zeigen, ihren Wert ändert. So würdest du zumindest die Konsistenz der Datenbank nicht gefährden.

mfg, metax.

 

[LX]

Wozu soll das denn gut sein?

Das ist der springende Punkt. Außer "optischen Gründen" gibt es eigentlich nix, was dafür sprechen würde, sich die potenziellen Probleme, die das Aufrücken mit sich bringt, ans Bein zu binden. Und die Optik hat in der Datenbank nix verloren, das ist Sache der Ausgabe. Wenn man eine Liste in der Ausgabe durchnummerieren möchte, kann man auch einfach einen Counter mitlaufen lassen, statt die tatsächlichen IDs anzupassen.