Wie eindeutige Rechnungsnummer in DB erstellen und speichern?

[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

[nahpets]

Wir hatten mal in 'nem Projekt bei den Sequenzen ein "Schrittweite" von 128.

Man holte sich also von der Sequenz einen Wert und konnte dann diesen, plus die nächsten 127 fortlaufenden Werte, "verbraten".

Wenn das nicht reicht, holte man sich den nächsten 128 Wertebereich.

Und wenn man sie nicht alle brauchte, dann gab's halt Lücken, ja und? Ist (zumindest) bei technischen Schlüsseln vollkommen wurscht.

Und gibt es irgendeine zwingende Erfordernis, dass Rechnungsnummern zwingend lückenlos aufsteigend nummeriert sein müssen?

Ob große Unternehmen, die täglich hunderte oder tausende von Rechnungen erstellen, wirklich darauf achten, dass die Nummer garantiert lückenlos vergeben wurde.

Es kann nun mal bei der Erstellung einer Rechnung passieren, dass der Vorgang abgebrochen werden muss. Dann ist diese Rechnungsnummer halt vergeben, obwohl diese Rechnung letztlich nie erstellt wurde.

Die "zwingende Lückenlosigkeit der Rechnungsnummer" ist nur was zur Befriedigung des persönlichen Ergeizes des vor dem Rechnersitzenden oder irgendeines "Verwaltungstieres", aber für den Kunden oder die weiter interne Verarbeitung vollkommen Irrelevantes.

Habe heute eine Rechnung mit der Nummer 21750094056 bekommen. Mir ist es doch sowas von wurscht, ob es die Nummern 21750094055 und 21750094057 gibt oder nicht. Und für den Rechnungsersteller dürfte das auch absolut egal sein, die Buchhaltung will nur irgendwann wissen, ob für jede erstellte Rechnung irgendwann (möglichst vor dem letztmöglichen Zahlungstermin) ein Geldeingang zu verbuchen ist.
Aber niemand wird die Rechnungen nach lückenlos aufsteigender Rechnungsnummer ablegen und irgendein Problem dabei bekommen, wenn da mal 'ne Nummer fehlt.

Meiner Meinung nach werden hier oft "fachliche Anforderungen" gestellt, die für die tatsächliche Verarbeitung völlig überflüssig sind. Man könnte für die Rechnungsnummer auch einfach die Millisekunden seit dem 1.1.1970 nehmen, man darf nur nicht auf die Idee kommen, die Uhr zurück zu stellen. Die Verarbeitung der Rechnungen im weiteren Geschäftsablauf dürfte dadurch in keiner Weise nachteilig beeinflusst werden.

Mit Anforderungen wie: "Die Rechnungsnummer muss aus Jahr, Monat und einer fortlaufenden Nummer bestehen." sorgen bei der Implementierung eigentlich nur für Probleme, ohne dass im eigentlichen Arbeitsablauf dadurch ein wesentlicher Nutzen entsteht.

[himitsu]

Zitat von nahpets:

Und gibt es irgendeine zwingende Erfordernis, dass Rechnungsnummern zwingend lückenlos aufsteigend nummeriert sein müssen?

Das kann manchmal als Anforderung im Raum stehen, quasi als Beweissicherung.

Wenn irgendwo eine Lücke ist, dann fehlt etwas
und wenn was fehlt, dann könnte sich z.B. ein Wirtschaftsprüfer denken was da denn fehlen mag.
'ne hinterzogene Eingangsrechnung? Steuerhinterziehung? Ein Datenfehler/verlorener Datensatz? ...?

[EmWieMichael]

Zitat von nahpets:

...
Und gibt es irgendeine zwingende Erfordernis, dass Rechnungsnummern zwingend lückenlos aufsteigend nummeriert sein müssen?
...

Der Gesetzgeber fordert fortlaufende Rechnungsnummern, die allerdings keineswegs lückenlos sein müssen; wichtig ist ihre Eindeutigkeit.

[jobo]

Also von Lückenlosigkeit war seitens des TE keine Rede. Dazu müssen wir uns in diesem Thread nicht den Kopf zerbrechen (es gibt dazu genug eigene Threads).

Datumsteile dagegen als Bestandteil der Rechnungsnummer und die fortlaufende Nummer mit Reset und Eindeutigkeit war eine Anforderung.
Da ist ein Hinweis zur Sinnhaftigkeit sicher nicht verkehrt. Aber zu sagen ~"..diese Anforderung brauchst Du nicht..", ist aus der Ferne m.E. nicht vertretbar. Denn tatsächlich kennt niemand die Vorgänge vor Ort, Ablage und Suchverfahren in der Buchhaltung usw. usf.

Wenn man mal die fachliche Schiene an Seite lässt:
Eine aufsteigende, eindeutige Sequenz in einer Wertegruppe zu erzeugen, sowas gibt es als Anforderung sicher nicht nur in der Buha.
Mich interessiert insofern eigentlich nur, ob das vorgeschlagene Verfahren praxistauglich ist, also robust und zuverlässig.