Wie fortlaufende Nr. in DB-Taballe erzeugen? Generator nicht möglich?

[DeddyH]

Wenn man das aber nicht dem Frontend überlassen will, wird es etwas komplizierter. Sofern mein Gedankengang richtig ist, bräuchte man 2 SPs: eine für das Erzeugen eines neuen Kontos (legt den Generator an) und eine für das Erzeugen einer neuen Buchung (holt sich den aktuellen Generatorwert und trägt ihn ein). Dann müsste man nur noch sicherstellen, dass das Einfügen von Datensätzen nicht mehr direkt, sondern nur noch über diese SPs möglich ist. So könnte es funktionieren, wenn ich mich nicht irre.

[mm1256]

Hallo,

sorry, den Gedanken mit den Generatoren kann man vergessen, wenn ich die FB-Einschränkungen hinsichtlich der maximal möglichen Generatoren lese. Das wird also nichts. Ein Standard-SKR-03 umfasst schon mal über 1000 Konten. Auch wenn die i.d.R. nicht alle bebucht werden, die Maximal-Grenze der Generatoren kann bei diesem Ansatz trotzdem schnell erreicht werden.

Ich bin kein FB-Spezialist, und darum weiß ich nicht wie man das mit FB löst. Die einzige praktikable Lösung die ich kenne und auch schon über Jahrzehnte in diesem Zusammenhang (z.B. eindeutige Belegnummern-Erstellung mit mehreren Nummernkreisen) einsetze ist eine Hilfstabelle mit den entsprechenden Nummern(-Kreisen) wo sich der Server vor dem "Post" automatisch die nächste Nummer holt und die zuletzt vergebene Nummer wieder zurückschreibt. Der Client darf bzw. sollte bei einer automatischen Nummernvergabe gar nicht involviert sein.

[Dejan Vu]

Zitat von mm1256:

...Die einzige praktikable Lösung die ich kenne... ist eine Hilfstabelle mit den entsprechenden Nummern(-Kreisen) wo sich der Server vor dem "Post" automatisch die nächste Nummer holt und die zuletzt vergebene Nummer wieder zurückschreibt.

Ist doch fein.

Code:

UPDATE NummernKreise 
   SET Nummer = Nummer + 1 
 WHERE NummernKreisPK = :MyNummernKreis 

RETURNING Nummer INTO :NeueNummer

Geht das so?

[Sir Rufo]

Zitat von Dejan Vu:

Zitat von mm1256:

...Die einzige praktikable Lösung die ich kenne... ist eine Hilfstabelle mit den entsprechenden Nummern(-Kreisen) wo sich der Server vor dem "Post" automatisch die nächste Nummer holt und die zuletzt vergebene Nummer wieder zurückschreibt.

Ist doch fein.

Code:

UPDATE NummernKreise 
   SET Nummer = Nummer + 1 
 WHERE NummernKreisPK = :MyNummernKreis 

RETURNING Nummer INTO :NeueNummer

Geht das so?

Und wenn man diese Zeile entsprechend innerhalb der Transaktion lockt, dann reißt es bei einem Rollback auch keine Löcher in den Käse die Folge.

Aufpassen muss man allerdings, wenn man (beim Buchen nicht ungewöhnlich) innerhalb einer Transaktion jeweils für zwei Konten eine fortlaufende Zahl benötigt. Dann muss man dass in einem Rutsch anfordern (oder wenigstens den Lock anfordern), sonst kann es in dieser Situation zu einem Deadlock kommen.

[Dejan Vu]

Wenn man keine Löcher will, müsste der Transaction Level 'SERIALIZABLE' eingestellt sein. Das ist dann aber tödlich für die Performance. Irre ich mich da?

[jobo]

Ich denke auch, dass man hier aufpassen muss, nichts durcheinander zu werfen.
Das beginnt damit, wie die (fachliche?) Anforderung für die aufsteigende, lückenlose Konto abhängige Buchungsnummer begründet ist bzw. in der Praxis verwendet wird.
Das ist zu trennen von der technischen Anforderung nach einem eindeutigen Schlüssel für die Buchung, die
a) sicher ohne probleme über einen Generator (Sequence) abzuwickeln ist
b) so oder so transaktionssicher (auch ohne Table Lock!) funktioniert
c) prinzipbedingt Lücken hinterlassen kann
d) table lock kann in belasteten Umgebungen drastische Performanceprobleme mit sich bringen

Wenn die technischen Anforderungen also mit einem Generator unproblematisch zu erfüllen sind (was wahrscheinlich so ist), dann hat man vielleicht nur noch ein Darstellungs(!)problem für die Buchungsnummern.

Das Darstellungsproblem könnte man glaub ich auch unter Firebird als zusätzliches Feld über die Rankfunktion virtuell erzeugen, on the fly, also immer lückenlos, weil frisch generiert, auch wenn mal alle Buchungen in die Tonne kommen sollten.
Hab grad nicht ganz klar, ob das schon unter 2.5 so da ist, oder erst unter V 3.

[Dejan Vu]

Zitat von jobo:

Das Darstellungsproblem könnte man glaub ich auch unter Firebird als zusätzliches Feld über die Rankfunktion virtuell erzeugen, on the fly, also immer lückenlos, weil frisch generiert, auch wenn mal alle Buchungen in die Tonne kommen sollten.

So eine Buchungsnummer ist immer auch ein Schlüssel. Bei Rechnungsnummern hast Du ja das gleiche Problem. Die müssen ja auch lückenlos sein.
Das Performanceproblem kann man auch über bulk inserts umgehen, falls der use case in der Praxis auftaucht.

[mjustin]

Zitat von Dejan Vu:

So eine Buchungsnummer ist immer auch ein Schlüssel. Bei Rechnungsnummern hast Du ja das gleiche Problem. Die müssen ja auch lückenlos sein.

Wie ist "Lücke" definiert?

Zitat:

Die Rechnungsnummern dürfen also je nach Kunden oder Produkten unterschiedlichen Text enthalten. Sie brauchen nicht lückenlos aufeinander zu folgen.

Erlaubt sind zum Beispiel folgende Rechnungsnummern:

2008.25.0167
Interkauf-1267.10.08
10875-web-345-08

http://www.steuer-schutzbrief.de/ste...alig-sein.html