Wie eindeutige Rechnungsnummer in DB erstellen und speichern?

[DCoderHH]

Zitat von rokli:

es gibt auch die Möglichkeit, eine Tabelle anzulegen, in der die Nummern verwaltet werden

Wie würde man die Tabelle in einer Multiuser-Umgebung abfragen und setzen so dass es keine doppelten Nummern gibt? Ein einfaches select und update würde ja nicht funktionieren...

[mkinzler]

Zitat von DCoderHH:

Zitat von rokli:

es gibt auch die Möglichkeit, eine Tabelle anzulegen, in der die Nummern verwaltet werden

Wie würde man die Tabelle in einer Multiuser-Umgebung abfragen und setzen so dass es keine doppelten Nummern gibt? Ein einfaches select und update würde ja nicht funktionieren...

Man könnte ein select for update verwenden.

[jobo]

Zitat von mkinzler:

Zitat von DCoderHH:

Zitat von rokli:

es gibt auch die Möglichkeit, eine Tabelle anzulegen, in der die Nummern verwaltet werden

Wie würde man die Tabelle in einer Multiuser-Umgebung abfragen und setzen so dass es keine doppelten Nummern gibt? Ein einfaches select und update würde ja nicht funktionieren...

Man könnte ein select for update verwenden.

Nach meinem Verständnis läuft das automatisch in einer Transaktion ab und würde keine Probleme bereiten. Dafür ist ja der Generator und Transaktionsicherheit da.

Notfalls mal ausprobieren und ein paar Consolen öffnen die in einer Loop Werte anfordern. Dazwischen manuel das Datum zurücksetzen. Dabei sollte nur eine einzige Sitzung einen Sequenzreset "erleben" und natürlich alle Sitzungen in Summe eindeutige Nummern liefern.

@Datumsgrenzen: Die sind natürlich international unterschiedlich. Das ist aber kein technisches Problem, sondern muss per Konvention vereinabrt werden, welche Datumsgrenze gewählt werden soll.

Ich selbst habe bei meinem Vorschlag eigentlich ein anderes Problem. Nämlich das Sequenzreset selbst. Ich bin mir nicht ganz sicher, wie das zu werten ist, aber es scheint als DML Befehl zu laufen und ich kenne es von anderen Systemen so, dass DML implizit commited. Das wäre aus meiner Sicht nicht wünschenswert.

[p80286]

Ich möchte nochmal anmerken, daß diese datumsabhängige Generierung nur für einen geografisch begrenzten Raum durchführbar ist. Egal ob LocalTime oder eine zentrale Zeit (Greenich) irgendwann ist eine Datumsgrenze erreicht, die mit einem "Datumsgefühl" kollidiert. Alleine in den USA gibt es eine Zeitdifferenz von 3 Stunden, Die Westküste hat einen Abstand von 9 Stunden zu Deutschland, wenn dort die erste Rechnung generiert wird, ist bei uns die letzte im System. Aber für solche Szenarien wurde die Datenbank nicht entworfen, und das Jahr 2000 war in weiter Zukunft.

Gruß
K-H

[Ghostwalker]

Zitat von p80286:

Ich möchte nochmal anmerken, daß diese datumsabhängige Generierung nur für einen geografisch begrenzten Raum durchführbar ist. Egal ob LocalTime oder eine zentrale Zeit (Greenich) irgendwann ist eine Datumsgrenze erreicht, die mit einem "Datumsgefühl" kollidiert. Alleine in den USA gibt es eine Zeitdifferenz von 3 Stunden, Die Westküste hat einen Abstand von 9 Stunden zu Deutschland, wenn dort die erste Rechnung generiert wird, ist bei uns die letzte im System. Aber für solche Szenarien wurde die Datenbank nicht entworfen, und das Jahr 2000 war in weiter Zukunft.

Gruß
K-H

Da hast du definitiv recht. Aber das Problem hast du generel mit Datumswerten, egal ob das nun in der
Rechnungsnummer oder sonstwo in der DB ist. Deshalb sollte man sich hier (Programmintern) auf eine Art einigen (i.d.R. GMT).

[rokli]

Hallo DCoderHH,

Zitat von DCoderHH:

Zitat von rokli:

es gibt auch die Möglichkeit, eine Tabelle anzulegen, in der die Nummern verwaltet werden

Wie würde man die Tabelle in einer Multiuser-Umgebung abfragen und setzen so dass es keine doppelten Nummern gibt? Ein einfaches select und update würde ja nicht funktionieren...

Auch ein Status-Feld wäre möglich, z. b.:
User 10 setz Status = 10 => kein anderer darf eine Nummer generieren
User 10 generiert seine neue Nummer und trägt sie ein
User 10 setze Status = 0 => jemand anderes kann eine Nummer ziehen

[jobo]

Eine solche logische Sperre würde doch nichts an dem Multiuser Problem ändern (das es m.E. gar nicht gibt), sondern es nur verschieben.
Gäbe es das Multiuser-Zugriffs-Problem, würde es beim Statusupdate genauso auftreten, also nur bei einem anderen Updatebefehl.

[nahpets]

Sagen wir mal so, 'ne Sequenz wird aufgerufen und gibt 'nen Wert zurück.

Multi-User hin oder her, die Datenbank kann die Sequenz nur einmal gleichzeitig aufrufen. Egal wieviele User unterwegs sind, sie müssen dann eben warten, bis die Datenbank die Sequenz aufruft, den Wert liefert und entsprechend hochzählt.

Die Sequenzen / Generatoren sind ja gerade dafür da, im Multiuserbetrieb sicherzustellen, dass eine Nummer nur genau einmal geliefert wird, egal wieviele User da in welchem, von der Länge her gegen 0 tendierenten, Zeitraum abfragen. Im Gegensatz zur Verwaltung mit Statuswerten ... in welchen Tabellen auch immer, soll hier ja das Multiuserproblem behoben werden.
Sollte es bei Sequenzen und / oder Generatoren aber trotzdem mal ein Problem geben, weil die Dinger einen Wert mehrfach geliefert haben, würde ich die Datenbank (wegen schlechter Implementierung / Fehlerhaftigkeit) wechseln.

Ich persönlich halte es für unsinnig, kontraproduktiv und absolut überflüssige Fehlerquellen generierend, wenn ich einen eindeutigen Wert benötige und diesen per Sequenz / Generator erhalten kann, nach einer anderen Lösungsmöglichkeit zu suchen. Meiner Meinung nach ist das einfach nur Quatsch.

Hab' da noch was gefunden:

Wat is 'ne Sequenz:

Zitat von IBM:

Eine Sequenz ist ein Datenbankobjekt, das die automatische Generierung von Werten wie zum Beispiel Schecknummern ermöglicht. Sequenzen eignen sich ideal für die Aufgabe der Generierung eindeutiger Schlüsselwerte. Anwendungen können Sequenzen verwenden, um mögliche Probleme in Bezug auf den gemeinsamen Zugriff und die Leistung infolge von Spaltenwerten zu vermeiden, die für die Protokollierung von numerischen Werten verwendet werden. Der Vorteil von Sequenzen im Vergleich zu außerhalb der Datenbank erstellten numerischen Werten besteht darin, dass der Datenbankserver die generierten numerischen Werte protokollieren kann. Durch einen Systemabsturz mit anschließendem Wiederanlauf werden keine doppelten Zahlenwerte generiert.

siehe: http://www.ibm.com/support/knowledge.../c0023175.html

[jobo]

Zitat von nahpets:

Sagen wir mal so, 'ne Sequenz wird aufgerufen und gibt 'nen Wert zurück.
..

Das sehe ich im Prinzip alles haargenauso.
Ohne Not muss man nicht rumzaubern mit solchen Nummern.
Eine Sequenz ist eine Sequenz.
Transaktionssicherheit ist Transkationsicherheit.
Ein DB, die das nicht kann, sollte man nicht nutzen.

Die Sequenz wird also immer(!) fortlaufende Nummern produzieren, auch im Multiuserbetrieb. Das sollte vollkommen klar sein.
Und der Reset mit dem drangeflickten Datum, da bin ich der Meinung, dass es genauso geht, aber das sehen die Leute hier teilweise offenbar kritisch- auch wenn noch niemand gesagt hat warum.

Letztlich ist es Sache des TE, das abzuwägen und ggF. zu testen.

Vielleicht hätte ich nicht sagen sollen, dass ich mir nicht sicher bin, ob das Vorgehen wasserdicht ist für fb.

Am Ende ist es ja so- ich traue mich kaum, es zu sagen:
Falls der Mechnismus selbst fehlschlagen würde (das wäre entgegen meiner Implementierung nicht einmal pro Tag ab Mitternacht, sondern einmal im Monat ab Mitternacht laut Anforderung) würde eine doppelte Rechnungsnummer immernoch durch einen Unique Constraint abgewiesen. Es werden also keine falschen Daten gespeichert. Auch dafür sind moderne DB gemacht.

[p80286]

Was vielleicht für Irritationen sorgt, ist, daß es Sequenzer gibt, die z.B 10 Nummern auf Vorrat erzeugen, und unter widrigen Umständen ist dieser Vorrat dann verloren.
Das ist aber letztlich egal, da es darum geht eine eindeutige Nummer zu erzeugen.

Gruß
k-H