Wie eindeutige Rechnungsnummer in DB erstellen und speichern?

[himitsu]

MultiUser: Man nehme einen Generator (wie bei den AutoInc-Feldern) für den numerischen Anteil.
Und dann baut man sich 'ne DB-Funktion, die einen neuen AutoInc-Wert generieren lässt und dann YYYY, MM, DD mit AutoInc zusammensetzt und als VARCHAR rausgibt.
Diese Funktion könnte man z.B. auch als DEFAULT an ein Feld hängen und von der DB füllen lassen.

Wir haben bei uns 'ne Tabelle und paar Funktionen, wo mehrere solcher "Masken" definiert werden können, auch kundenabhängig, die man dann an irgendwelche Felder hängen kann oder im Programm abfragt.
Teilweise ist dann noch 'ne Lückenprüfung mit drin, welche abgefragte, aber dann doch nicht verwendete Werte findet und erneut nutzen kann.
Bei uns werden diese Werte, sowie die anderen DEFAULT-Werte, meistens nicht erst beim Post von der DB eingetragen, sondern schon von der Query-Komponente im OnAfterInster geladen, damit der User Diese bereits im Grid/den Edits sehen kann, bevor er speichert.

[jobo]

@himitsu
Genau das habe ich ja gemacht und es wird angezweifelt, dass es mutliuser fähig ist.

[himitsu]

Man muß halt die Generatoren/Sequenzen verwenden, diese sind quasi threadsave und werden auch nicht von Transaktionen beeinflusst.

Wenn man diese Zähler in eigenen Tabellenfeldern speichert ... nja, kommt dann halt drauf an, wie das DBMS mit gleichzeitigen Abfragen/Updates umgeht, die auf die selben Felder zugreifen.
UPDATE meinezählertabele SET zähler = zähler + 1 WHERE name = :name RETURNING zähler

[jobo]

Mach ich auch, zusätzlich aber noch ein Update auf eine Merkertabelle für den Datumswechsel.

[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

[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.