MariaDB: Auto_INcrement

Mikana

Benutzer
Beiträge
17
Moin ihr Menschlein,

heute melde ich mich mal wieder mit einem anderen Problem, nachdem ihr mir schon sehr erfolgreich bei dem Foreign Key Problem helfen konntet.

Es geht mal wieder um das Modell-Unternehmen “Funkel-Reisen“.

Ich habe einen Auto_Increment für FahrtenID eingesetzt. Mein Klassenkamerad und ich haben die Tabelle Probeweise mit einem vollen Datensatz gefüllt, den ich nun wieder gelöscht habe, damit ich den richtigen Datanesatz nehmen kann.
Die .txt sende ich im Nachtrag natürlich auch wieder mit!

Nunja. Der Test-Datensatz erhielt durch AUTO_INCREMENT die FahrtenID 1.
Nach löschen und einpflegen der richtigen Daten war in meiner Logik ein „entweder er fängt wieder bei 1 an, weil gelöscht„ oder „vielleicht zählt es durch AUTO_INCREMENT aber auch automatisch weiter und an erster Stelle steht 2?“
Die zweite Option traf dann auch ein. Und an zweiter Stelle zählt FahrtenID mit 3 weiter.

Kann ich das nachträglich ändern?
Oder müssen wir jetzt alles händisch einzeln ändern?

Lg,
Mikana
 

Anhänge

  • Funkel_Reisen_Sierig-Last.txt
    15,9 KB · Aufrufe: 3
Werbung:
Das ist vollkommen in Ordnung so. Nicht vielleicht nach menschlichem Denken, aber in Datenbanken.
Die ID hat keine(!) Bedeutung außer dass sie eindeutig sein muss. Keine Ordnung, keinen Typ, nichts sonst. Die ID kann also absteigenend bei 10 Billionen losgehen, zufällig sein, aus Buchstaben oder Zeitangaben bestehen, meinetwegen auch aus JPG Images.
Sie muss nur eindeutig sein.
Dass in der Praxis Autoincrement und ähnliches verwendet wird, ist lediglich ein pragmatisches (das pragmatischste-je nach Bedarf und Möglichkeiten) Verfahren, einen eindeutigen Wert zu kreiren.

Du musst nichts machen, auch nicht rückgängig.
 
Prinzipiell dient diese ID typischerweise als PRIMARY KEY und hat nur eine Aufgabe: eindeutig zu sein. Ob da Lücken sind oder nicht spielt exakt KEINE Rolle. Selbst bei einer nicht abgeschlossenen Transaktion (Rollback) wird der Wert verworfen und taucht nicht mehr auf.

Du kannst aber auch den Wert zurücksetzen, zumindest in PostgreSQL, siehe 9.17. Sequence Manipulation Functions
 
Ach so:
Dieser Sachverhalt hat natürlich konsequenzen. Du musst nicht nur nichts machen, Du musst auch damit rechnen, dass es so ist und keine Verfahren "einbauen", die etwas anderes annehmen. Verfahren, die von Lückenlosigkeit ausgehen oder die nur davon ausgehen, dass eine neuere ID größer ist, als eine ältere, ... niemals benutzen. Schlüsselfelder werden nur zum joinen benutzt. Punkt. Ende.
 
Also ist das so in Ordnung und ich muss mir keine Sorgen um meine Note machen? Vorgaben haben wir nämlich keine, außer den Tabellen in der 3. Normalform =)
 
Werbung:
Nein, keine Sorgen machen. Du kannst ja sicherheitshalber noch mal schauen, ob die 3.Normalform etwas über Lückenlosigkeiten sagt.
Wenn Du im Unterricht etwas dazu gehört hast, kann das eigentlich nur in sehr speziellen fachlichen Angelegenheiten sein, die berühmte Rechnungsnummer z.B., da streiten sich immer alle. Ist aber letztlich eine Sache, die das Finanzamt (der Kunde) entscheidet, nicht die DB Theorie.
Einen Punktabzug könntest Du am ehesten bekommen, wenn ein Teil Deiner Arbeit den Fehler macht, von Lückenlosigkeit auszugehen, ohne dass Du für Lückenlosigkeit sorgst.
Wie gesagt, das braucht keine Mensch.
Es deswegen einen Punktabzug gibt, bin ich gerne zu Verhandlungen mit dem Prüfer bereit.
 
Zurück
Oben