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

[DeddyH]

Das ist aber völlig normal: einmal angefasst, ist die Nummer weg, egal ob verwendet oder nicht.

[Jumpy]

Wenn man die angelegte ID nicht direkt wieder braucht, wäre es über ein Insert-Statement doch einfach möglich, oder geht sowas (Subselect in insert) nicht?

SQL-Code:

insert into tabelle (Konto,Buchungsnummer,Text)
Select
  '4600' as Konto,
  (Select Max(BuchungNr)+1 From Tabelle Where Konto='4600'),
  'Irgendein Text'
From
  InOracleWürdeIchHier"DUAL"nehmen

Evtl. kann man sowas in eine SP packen, die dann die ID noch zurück liefert?

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

[hoika]

Hallo,

ich würde auch eine eigene Tabelle oder ein Feld in der Kontentabelle benutzen.
Das Select Max() ist soweit OK, solange ein Unique Index auf den sntsprechenden Felder ist.
Kommt es zu einer key-Exception (duplicate value), muss ich mir nochmal den neuen Wert holen, solange, bis es klappt.

FB kann etwa 32.000 (32758) Generatoren haben (http://www.firebirdsql.org/pdfmanual...ator-Guide.pdf), aber ich würde das nicht ausreizen,
vielleicht werden es ja mal doch mehr Konten und dann müßte der Code komplett umgebaut werden.


Heiko

[p80286]

Und warum nicht ein Generator für alle Konten?
Dann ist jede Buchung eindeutig
und bei einem

SQL-Code:

insert

wir das so gemacht

SQL-Code:

insert into my table (id,...) values((SELECT NEXT VALUE FOR MyGeneratior FROM RDB$DATABASE),....)

Gruß
K-H

[himitsu]

Zitat:

Zitat von mjustin (Beitrag 1279079)

Einzige Einschränkung:
immer wenn eine neue Nummer generiert, aber (weil ein Fehler auftritt) nicht beim INSERT verwendet wird, wird diese Nummer unbenutzt und es bleibt eine "Lücke". (Da Generatoren ihre Werte ausserhalb von Transaktionen erhalten, können diese nicht durch ein Rollback verhindert werden.)

Dann kopiert man das eben nicht manuell, sondern läst sich die Nummer in einem BeforeInsert-Trigger erzeugen und einfügen. :angel:

Da geht der Wert nur noch verloren, wenn es beim Insert knallt.

Es ist aber vom Programm unabhängig
und es gibt keine Probleme, wenn mehrere Connections parallel arbeiten und wenn es beim Insert etwas dauert. (deswegen sind Generatoren auch unabhängig von Transaktionen)

[Hansa]

Hier im gesamten Thema sind mindestens 2 grundsätzliche Fehler zu sehen und noch etliche Kleinere :

1. Generatoren zu benutzen, um Datenabank-Felder durchzunummerieren. Und dann noch ohne Lücken ? Ohne Transaktionssteuerung ? Das sind nackte Zahlen ohne weitere Bedeutung. Ob da jetzt 1 steht oder 8937598 ist völlig egal. Das dient nur der Identifikation eines Datensatzes und eben der lückenlosen Weitergabe an abhängige Tabellen. Gibts diese Nr. nicht, dann ist eben kein Datensatz mit dieser ID vorhanden. Ob der jetzt zwischenzeitlich gelöscht wurde oder sonstwas interessiert da vorerst nicht.

2. Generatoren-Werte einzusparen. :wall: Was soll das ? Ist die 1 jetzt billiger als die 8937598 ? :shock: Wem integer (ca. 4.000.000.000 Werte möglich) nicht reicht, der soll eben bigint (64bit-Integer) nehmen. Wenn ich nicht irre sind das ca. 10 hoch 20, also 1 mit 20 Nullen. Nehmen wir mal 10 hoch 9 Menschen, dann hat jeder (bleibe mal bei Buchungen) 10 hoch 11 Buchungen im Leben zur Verfügung. Sagen wir mal weiter, jeder wird 100 Jahre alt, dann kann er im Jahr 10 hoch 9 Buchungen mache. Das würde bei 31.000.000 Sek. / Jahr pro Sekunde dann immer noch 32 Buchungen / Sek. ergeben.

P.S.: ich kenne das angebliche Bill Gates Zitat mit den 64 kB auch ! Bzw. das : "Niemand hat die Absicht eine Mauer zu errichten" :mrgreen:

[Dejan Vu]

Zitat:

Zitat von mm1256 (Beitrag 1279084)

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

Zitat von Dejan Vu (Beitrag 1279138)

Zitat:

Zitat von mm1256 (Beitrag 1279084)

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