Nächsten Autoindex ermitteln

[Crake]

Ich möchte auf meiner Bestellseite jedem Auftrag eine fortlaufende Nummer vergeben. Aus diesem Grund habe ich der entsprechende Spalte in der Tabelle die Eigenschaft Auto_Increment vergeben.

Da ich nun den Autoindex für die Erstellung der Rechnung benötige, wäre es sinnvoll den nächsten Autoindex zu ermitteln und diesen als Auftragsnummer zu vergeben.

Theoretisch stellt es kein Problem dar, den größten Wert einer Spalte (Primary Key) auszulesen und dann die Daten im nächsten Datensatz manuell zu speichern. Allerdings entspricht diese Lösung nicht wirklich meinen Ansprüchen.

Wie ermittele ich nun den nächsten Autoindex?

Edit: Es hilft nichts, den größten Wert zu ermitteln, wenn auto_increment gesetzt ist, da bei Entfernung der Zeilen, dann Probleme auftreten.

Danke,
Stephan Altmann

[mrhappiness]

was spricht dagegen, erst die daten in die db einzutragen und dann die id des zuletzt eingefügten datensatzes auszulesen?


wenn du das nicht machen willst:

SHOW TABLE STATUS LIKE 'tabellenname'

[Crake]

Original geschrieben von mrhappiness
was spricht dagegen, erst die daten in die db einzutragen und dann die id des zuletzt eingefügten datensatzes auszulesen?

Mir ist es bereits passiert, dass sich 2 Angaben überschnitten. Es ist zwar unwahrscheinlich, dass dieses Problem erneut auftritt aber swicher ist halt sicher.

Ansonsten Danke

[mrhappiness]

Original geschrieben von Crake
Mir ist es bereits passiert, dass sich 2 Angaben überschnitten

dann machst du was falsch

die methode is sicherer als das was du vborhast, wie hast du's denn probiert?

[Crake]

Daran war nichts falsch, es war lediglich reiner Zufall. Es wurden 2 Abfragen nahezu zeitgleich ausgeführt.

Mit der anderen Methode kann ich eine ID für das Eintragen vorbestimmen. Existiert ein Eintrag bereits, dann kann ich mit Hilfe meiner Datenbankklasse den Fehler problemlos abfangen.

[mrhappiness]

2 abfragen nahezu zeitgleich?
aber von verschiedenen pcs aus oder?

wenn du bei jedem pc nach dem INSERT die funktion mysql_insert_id(); aufrufst, hast du gar keine fehler die du abfangen können müsstest

[Abraxax]

@happy
lass ihn das doch manuell machen ... so könnten sich seine zufälle ja häufen...

[mrhappiness]

das wäre aber nicht nett und montags bin ich immer im auftrag ewiger jugend und glückseligkeit unterwegs

[Abraxax]

OffTopic:

---

aber er will sich ja nicht helfen lassen. warum hätte er sonst deinen vorschlag ignoriert?

---

[Crake]

Herzlichen Dank für die liebevollen Kommentare

Bei dem o. g. "Zufall" handelte es sich um einen Online-Shop, den ich im Auftrag meiner Firma für einen größeren Kunden erstellt hatte. Es ist ziemlich unwahrscheinlich, dass sich ein entsprechendes Ereignis erneut wiederholt, aber ich bin halt lieber auf der sicheren Seite.

[TobiaZ]

naja, nachvollziehbar ist es schon. aber wenn du anders herum vorgehst, wir es mit sicherheit nicht sicherer.

[MelloPie]

nachvollziehbar is es?
die MEthode hat einen höheren unsicherheitswert als die last_insert_id variante...

[Crake]

Original geschrieben von MelloPie
nachvollziehbar is es?
die MEthode hat einen höheren unsicherheitswert als die last_insert_id variante...

Soetwas lässt sich ohne entsprechende Argumentation leicht behaupten.

Also zu Erklärung:
Ich ermittele im vorhinein den nächsten Auto_increment-Wert. Anschliessend speichere ich den Eintrag unter zu Hilfenahme des zuvor ermittelten Auto_Inrement-Wertes.

Sollte sich zufällig eine Abfrage erneut überschreiten, dann wird ein MySQL-Fehler hervorgerufen, den ich problemlos mit meiner Klasse abfangen kann.

[TobiaZ]

nachvollziehbar is es?
die MEthode hat einen höheren unsicherheitswert als die last_insert_id variante...

ich sach ja auch. andersrum ist garantiert noch schlechter. vorallem weil die wahrscheinlichkeit eigentlich so gering ist. vielleicht wurde aber auch einfach nur zu spät die id geholt.

[TobiaZ]

@crake: naja, wenn ich lastinsertid aber direkt nach dem Query (idealerweise direkt in der Klasse) ausführe, sollte es da aber keine probs geben.

Wenn du ganz sicher gehen willst, dann sperr die DB, aber wie schon mehrfach gesagt, dass das in den nächsten 10 Jahren (und dazu noch in einem online-shop) nochmal vorkommt, ist bei korrekter programmierung eigentlich nicht vorstellbar.