letzte Id bestimmen

[Sen]

Super! Danke.

Die Rechnungsnummern müssen nur logisch fortlaufend sein. Soweit ich weiß könnte dass auch

2005-0001
2005-0002
und im nächsten Jahr dann
2006-0001
usw. sein.

Rechnungsnummern per auto_increment zu erzeugen ist doch relativ sicher oder? Der Index kann nicht durch eine Optimize oder ähnliches durcheinander gebracht werden?

Die PHP-Lösung würde mir das Gefühl von mehr Kontrolle geben, aber da sind ja meine oben genannten Bedenken. Oder gibt es eine Möglichkeit ein Feld immer wieder upzudaten und gleichzeitig den neuen Wert zurückzugeben (ohne zwei Abfragen machen zu müssen). Irgendwie werd ich da aus der MySQL-Dokumentation nicht so richtig schlau.

[Sen]

Ok, vielleicht kann mir ja doch nochmal jemand helfen.

Ich habe eine Tabelle, die die letzte Rechnungsnummer vorgibt. Sie hat die Felder jahr, monat, nummer.

Für jeden Monat wird ein neuer Eintrag gemacht und dann soll das Feld nummer dieses Eintrages den gesamten Monat immer wieder um eins erhöht werden. Kann man das Feld nummer in ein und der selben Abfrage erhöhen und den neuen Wert zurückgeben?

Mit auto_increment läßt sich das leider nicht lösen. Die Rechnungsnummern würden irgendwann zu lang und ich müsste für jeden einzelnen Kaufvorgang einen Eintrag machen (was irgendwann eine ziemliche Datenmenge gibt).

Vielleicht seh ich auch den Wald vor lauter Bäumen nicht mehr und es gibt ne bessere Lösung.

[|Coding]

Wenn Du die Spalte der Rechnungsnummer auf BIGINT setzt, dann glaube ich kaum, dass Du jemals diesen Rahmen sprengen wirst...

BIGINT Bereich als unsigned: 0 bis 18446744073709551615
BIGINT Bereich als signid: -9223372036854775808 bis 9223372036854775807

[Sen]

Die Länge der Zahlen in der DB ist nicht das Problem. Je nach Länge sind die nur irgendwann nicht mehr nutzerfreundlich.

Sind meine Gedanken abwegig, dass sich zwei Bestellprozesse in die Quere kommen, wenn man das per PHP löst?

Vielen Dank für die Geduld mit mir.

[xabbuh]

Wenn du das so machen möchtest, brauchst du zwei Abfragen. Eine, die dir zunächst die nächste Bestellnummer ermittelt und eine zweite, die dann den Eintrag erstellt.

[Sen]

Ok. Danke. Denn werd ich mich mal an die Arbeit machen.

[|Coding]

Zitat von Sen

Die Länge der Zahlen in der DB ist nicht das Problem. Je nach Länge sind die nur irgendwann nicht mehr nutzerfreundlich.

Das ist aber halt ueblich. Schau dir doch mal die Rechnungen an die so bei Dir ankommen.

Zitat von Sen

Sind meine Gedanken abwegig, dass sich zwei Bestellprozesse in die Quere kommen, wenn man das per PHP löst?

Unmoeglich ist unmoeglich... Es ist durchaus denkbar, dass sich zwei oder mehrere Benutzer bei der Bestellung in die Quere kommen.

[xabbuh]

Zitat von |Coding

Unmoeglich ist unmoeglich... Es ist durchaus denkbar, dass sich zwei oder mehrere Benutzer bei der Bestellung in die Quere kommen.

Deswegen würde ich das Ganze über zwei Abfragen steuern. So kann man per LOCK TABLES verhindern, dass zwei identische Bestellnummern vergeben werden.

[Sen]

Ok, LOCK TABLES bringt mich weiter.

Eine Frage noch...Im MySQL-Handbuch habe ich nun folgendes gefunden:

Wenn Sie einen Tabellen-Handler in MySQL benutzen, der keine Transaktionen unterstützt, müssen Sie LOCK TABLES benutzen, wenn Sie sicherstellen wollen, dass kann anderer Thread zwischen einem SELECT und einem UPDATE dazwischen kommen kann. Das unten stehende Beispiel erfordert LOCK TABLES, um sicher ausgeführt zu werden...
http://dev.mysql.com/doc/mysql/de/lock-tables.html

Was ist mit dem Tabellen-Handler gemeint? Der Befehl HANDLER? Oder der in PHP benutzte Handler (z.B. $conn )?