SQL Primärschlüssel nach gelöschtem Datensatz neu vergeben?

[Crunor]

Hallo Computerbase'ler,

ich hätte eine kleine, kurze theoretische Frage zum Primärschlüssel in einer MySQL Datenbank.
In unserer Schule gibt es eine kleine Bibliothek, und deren Buchbestand soll nun in eine MySQL Datenbank eingetragen werden.

Als Primärschlüssel dient "ID", ist natürlich auf auto_increment gestellt. Wenn man nun aber einen Datensatz löscht und danach einen neuen anlegt, wird die ID des gelöschten Datensatzes mehr oder weniger "übersprungen" und neue, danach angelegte Datensätze beginnen nicht mehr mit der nächsten, logischen ID des letzten existierenden Datensatzes.

Hört sich konfus an, aber ich weiß es nicht besser auszudrücken. Im Anhang ist ein kleines Bild einer spartanischen Tabelle, was das "Problem" verdeutlichen soll. Der rote Strich ist da, wo früher (jetzt gelöschte) Datensätze gestanden haben - die nächsten Datensätze zählen einfach weiter, obwohl nach "103" eigentlich "104" kommen sollte. Doch da, wo der rote Strich ist standen früher mal 14 jetzt gelöschte Datensätze.

Ist eigentlich mehr ein "Schönheitsfleck" als ein Problem, doch kann man die dort übersprungen Primärschlüssel irgendwie neu vergeben? So für die Kosmetik? Ich weiß, dass es eigentlich nicht sinnvoll ist (besonders wenn man eine Abfrage auf Basis der ID macht und der Inhalt der gelöschten Datensätze einfach von einem neuen Datensatz dargestellt wird) aber gibt es nur so aus reinem Interesse eine Möglichkeit?

Danke,
Crunor

 

[web2]

Hallo Computerbase'ler,

Als Primärschlüssel dient "ID", ist natürlich auf auto_increment gestellt. Wenn man nun aber einen Datensatz löscht und danach einen neuen anlegt, wird die ID des gelöschten Datensatzes mehr oder weniger "übersprungen" und neue, danach angelegte Datensätze beginnen nicht mehr mit der nächsten, logischen ID des letzten existierenden Datensatzes.

Gut das es so ist! Die ID eines Datensatzes soll einen Datensatz einmalig machen - nicht mehr und nicht weniger. Dabei sollte die Form bzw. das Optische im Sinne von fortlaufender nummer keine Rolle spielen.

 

[Crunor]

Alles klar, damit hat sich das ja erledigt.
Ich hab das ganze nämlich in einer großen Tabelle stehen - und bisher sah die ID schön fortlaufend aus.

Naja, ich sollte mir Gedanken um ernstere Probleme machen.

 

[web2]

Kurzer Nachtrag.

Ich verstehe auch nciht warum du die ID in deiner Übersicht ausgibst. Der Informationsinhalt der Spalte ID ist ja ==0 ;-)

 

[Crunor]

Naja, angenommen jemand sucht Zuhause nach einem Buch und möchte es sich ausleihen. Da kann er ja zu uns *Buchhaltern* ( ) kommen und neben dem Titel und Untertitel einfach die ID angeben - ähnlich einer ISBN nur Schulintern.

So genau habe ich mir da aber auch noch nicht Gedanken gemacht, ist ja momentan noch eine Rohfassung.

 

[web2]

Davon würde ich dir abraten. Die ID würde ich lediglich für die Beziehung zu anderen Tabellen bzw. Datensätzen nutzen. Wenn du eine Spalte BuchNr hättest, könntest du mit deiner fortlaufenden Nummer wie gewohnt weitermachen ;-)

 

[PW-toXic]

wieso das denn?
der primärschlüssel ist durchaus auch für solche sachen zu gebrauchen. Es kommt zwar oft vor, dass der Primärschlüssel extern vom Softwaresystem nicht von belang ist, aber wenn er mal von Belang ist, dann sollte man ihn auch verwenden. Es spricht nichts dagegen.

 

[web2]

Das würde ich persönliche Vorliebe nennen. Ich habe ja auch geschrieben, dass ICH davon abraten würde.

Mann sollte ein Fahrrad zum Fahrradfahren benutzen, wobei man es auch schieben kann.

 

[krizzelfix]

Das mit dem Fahrrad ist richtig, web2.

Aber wenn man ein Datensatz suchen will und man hat einen Wert mit dem man Ihn genau identifizieren kann, fährt man da quasi mit dem Fahrrad. Wenn du es anders machen würdest, wäre es das Rad zu schieben.

 

[chorn]

Hi,

zur eindeutigen Identifizierung eines Buches in einer Sammlung von Büchern reicht die ISBN nicht aus - Bücher können auch doppelt vorkommen. Hier geht es um Exemplare, und die müssen einem Nutzer zugeordnet werden können, daher ist die Nutzung der ID zur Identifizierung des Exemplares unerlässlich.

MfG, Christian.

 

[Cobinja]

Natürlich kann man das als persönliche Vorliebe nennen.

Aber trotzdem hier mal ein (bisher nicht genanntes) Argument für Nutzung eines Primärschlüssels OHNE Nutzdaten:
Mal angenommen, es werden Fremdschlüsselbeziehungen zu den Büchern benutzt und dann wird eins gelöscht und die Primärschlüssel werden neu geschrieben, um echte fortlaufende Nummern zu haben, müsste jede Tabelle, die sich auf die Bücher bezieht, auch komplett durchforstet werden, um die richtigen Fremdschlüsseleinträge zu benutzen. Das ist schonmal nicht unbedingt vorteilhaft.

Wenn jetzt sogar irgendwann die Datenbank noch im nachhinein erweitert wird und neue Fremdschlüsselbeziehungen zu den Büchern erntstehen, müsste der Aktualisierungscode für oben genanntes Problem auch aktualisiert werden, um alle Tabellen zu behandeln. Und das kann schon schwerwiegender werden, je nachdem, wie die Aktualisierung durchgeführt wird (Über das Programm oder über die Datenbank).

Und das artet in völlig unnötiger Arbeit aus und lässt sich mit rein technischen Primärschlüsseln ohne Nutzdaten umgehen.

 

[PW-toXic]

ON DELETE CASCADE ist das schlüsselwort

davon abgesehn halte ich es trotzdem nicht gut, wenn eine buch ID ein weiteres mal vergeben wird. Nur weil ein buch im Archiv nichtmehr vorhanden ist, möchte man evtl trotzdem noch auf dieses eine Buch referenzen, wenn man zb sehen möchte, wie oft das buch schon ausgeliehn wurde oder solche sachen.

 

[Cobinja]

ON DELETE CASCADE ist das schlüsselwort

Das ist falsch.

ON DELETE CASCADE bedeutet, dass referenziernde Datensätze (Fremdschlüsselbeziehung) mitgelöscht werden, wenn der Referenzdatensatz gelöscht wird.

Was du meinst, ist ON UPDATE CASCADE. Damit lässt sich allerdings nur der erste Teil meiner Argumentation aushebeln. Das Durchsuchen und Neuschreiben der anderen Tabellen bleibt.

Und bei dem was du meinst, halte ich eine Fremdschlüssel-Beziehung nicht für sinnvoll, denn man kommt über einen Fremdschlüssel dann nicht mehr an die Buchdaten (Titel, Autor, etc.) ran. Sowas ist ein Fall für sinnvolle Redundanz (Und komm jetzt bitte nicht mit Normalisierung, die ist für Statistik-Tabellen nur bedingt anwendbar).

 

[-=Renegade=-]

Und bei dem was du meinst, halte ich eine Fremdschlüssel-Beziehung nicht für sinnvoll, denn man kommt über einen Fremdschlüssel dann nicht mehr an die Buchdaten (Titel, Autor, etc.) ran. Sowas ist ein Fall für sinnvolle Redundanz (Und komm jetzt bitte nicht mit Normalisierung, die ist für Statistik-Tabellen nur bedingt anwendbar).

Normalisierung ist sowieso in manchen Fällen nur bedingt nützlich, Denormalisierung kann schöne Performance Gewinne bringen.


so long

 

[PW-toXic]

ON DELETE CASCADE bedeutet, dass referenziernde Datensätze (Fremdschlüsselbeziehung) mitgelöscht werden, wenn der Referenzdatensatz gelöscht wird.

Was du meinst, ist ON UPDATE CASCADE. Damit lässt sich allerdings nur der erste Teil meiner Argumentation aushebeln. Das Durchsuchen und Neuschreiben der anderen Tabellen bleibt.

Nein ich meine ON DELETE CASCADE. Update interessiert hier niemanden, da ein Buch niemals seine ID ändern wird. Und wenn sie das tut, dann nur dann, wenn das buch einmal aus dem Archiv gelösct wurde und zu seinem anderen Zeitpunkt neu eingefügt wurde.

Das einzig interessante ist also, was passiert, wenn ein buch gelöscht wird. In diesem Fall sind alle anderen Einträge, die sich auf das Buch beziehen, uninteressant, und können gelöscht werden
=> ON DELETE CASCADE


edit: Ich verstehe nicht ganz warum hier Fremdschlüssel in irgendeiner Beziehung schlecht sein sollten, und wieso man hier irgendwo Redundanz gebrauchte könnte und sollte. Vielleicht kann mir das jemand mal genauer erklären, dann ich wittere hier einen schweren Denkfehler
Mit ON DELETE CASCADE muss man keine einzige zusätzliche Zeile code schreiben, und löst das Problem der "aktualisierung" der datenbank. Die Konsistenz ist somit jederzeit bewahrt.

 

[Cobinja]

Update interessiert hier niemanden, da ein Buch niemals seine ID ändern wird.

Genau darum geht es dem Thread-Opener aber. Er möchte seine Bücher durchnumeriert in der Tabelle stehen haben. Und für einen solchen Zweck wurde hier die Verwendung eines rein technischen Primärschlüssel und einer Spalte für die Durchnumerierung vorgeschlagen.

Diesen Vorschlag wollte ich unterstützen, nachdem ein anderer Vorschlag in die Richtung ging, den Primärschlüssel gleichzeitig für die Numerierung zu nutzen, und dabei mögliche Fremdschlüsselbeziehungen anscheinend vergessen, bzw. ausser Acht gelassen wurden.

Ein ON DELETE CASCADE sollte für solch eine Anwendung schonmal grundsätzlich verwendet werden, um keine inkonsistenten Daten in der DB stehen zu haben.

Die Redundanz habe ich nur ins Spiel gebracht, nachdem du mit dem Thema

Nur weil ein buch im Archiv nichtmehr vorhanden ist, möchte man evtl trotzdem noch auf dieses eine Buch referenzen, wenn man zb sehen möchte, wie oft das buch schon ausgeliehn wurde oder solche sachen.

gekommen bist.

Vielleicht kann mir das jemand mal genauer erklären, dann ich wittere hier einen schweren Denkfehler

Ich hoffe, diesen damit ausgeräumt zu haben.