firebird Trigger

[khh]

hallo zusammen,

ich weiss zwar nicht ob ich hier offtoppic bin, abert ich denke das gehört zu den DB.
Nachdem ich nun mein RDBMS zu firebird gewechselt habe,
vermisse ich die autoincrement Felder.
Bei meiner Suche bin ich auf den Tipp gestossen einen Trigger zu verwenden.
Leider kenne ich mich damit gar nicht aus, und die angegebene Syntax bringt bei der Verwendung mit IBexpert einen error

Delphi-Quellcode:

 ACTIVE BEFORE INSERT POSITION 0
 AS
 BEGIN
   IF (NEW.ID IS NULL) THEN
     NEW.ID = GEN_ID(GEN_TBL_TEST_ID,1);

wie geht das richtig?

Gruss KH

[Hansa]

Ist : GEN_TBL_TEST_ID grün unterstrichen ? Ansonsten fehlt das.

[mkinzler]

Wenn du den Trigger im IBExpert anlegen lässt, kannst du auch festlegen das der Generator automatisch erzeugt wird.

[Hansa]

Wo kann man das festlegen ? :shock: Unter dem Aspekt, dass man besser nur einen einzigen DB-weiten Generator anlegen sollte und nicht mehrere davon, womöglich für jede Tabelle einen, würde das auch keinerlei Sinn machen.

[khh]

Zitat:

Zitat von mkinzler

Wenn du den Trigger im IBExpert anlegen lässt, kannst du auch festlegen das der Generator automatisch erzeugt wird.

funktioniert jetzt, wenn ich den Generator manuell anlege.
Wo kann das definiert werden dass er automatisch erzeugt wird?


Gruss KH

[mkinzler]

Also ich lege immer pro Tabelle (für den PK) einen an. Was aus meiner Sicht auch sinn macht!

[DeddyH]

IIRC gleich auf dem ersten Reiter die beiden Checkboxen "Erzeuge Generator" und "Erzeuge Trigger" anhaken.

OK, sind doch 2 verschiedene Reiter. Übrigens lösche ich die If-Abfrage im Trigger immer raus, damit der Wert nicht von außen gesetzt werden kann. Dazu gab es vor langer Zeit mal einen Thread hier.

[Hansa]

Beim Anlegen neuer Tabellenfelder ist rechts eine Checkbox Autoinc. Wird die gecheckt, dann kann man für dieses Feld einen Generator anlegen oder existierenden benutzen.

Zitat:

Zitat von mkinzler

Also ich lege immer pro Tabelle (für den PK) einen an.

Macht man wohl zuerst intuitiv so. Danach aus Angewohnheit, oder um Zahlen zu "sparen". Kennt man sich einigermaßen aus, dann sollte man sich das aber besser wieder abgewöhnen. :mrgreen: Im Normalfall dürfte es keine Auswirkungen haben, aber für Profis in der Praxis irgendwann mächtig Ärger bedeuten.

[khh]

Zitat:

Zitat von DeddyH

IIRC gleich auf dem ersten Reiter die beiden Checkboxen "Erzeuge Generator" und "Erzeuge Trigger" anhaken.

OK, sind doch 2 verschiedene Reiter. Übrigens lösche ich die If-Abfrage im Trigger immer raus, damit der Wert nicht von außen gesetzt werden kann. Dazu gab es vor langer Zeit mal einen Thread hier.

ich danke euch


Gruss Kh

[Der Jan]

Zitat:

Zitat von Hansa

Zitat:

Zitat von mkinzler

Also ich lege immer pro Tabelle (für den PK) einen an.

Macht man wohl zuerst intuitiv so. Danach aus Angewohnheit, oder um Zahlen zu "sparen". Kennt man sich einigermaßen aus, dann sollte man sich das aber besser wieder abgewöhnen. :mrgreen: Im Normalfall dürfte es keine Auswirkungen haben, aber für Profis in der Praxis irgendwann mächtig Ärger bedeuten.

@Hansa: Verrätst du uns auch, warum?

[mkinzler]

Nein, denn Profis wissen das halt, wir blöden Amateure brauchen das gar nicht zu wissen :zwinker:

[khh]

Zitat:

Zitat von Hansa

Beim Anlegen neuer Tabellenfelder ist rechts eine Checkbox Autoinc. Wird die gecheckt, dann kann man für dieses Feld einen Generator anlegen oder existierenden benutzen.

Zitat:

Zitat von mkinzler

Also ich lege immer pro Tabelle (für den PK) einen an.

Macht man wohl zuerst intuitiv so. Danach aus Angewohnheit, oder um Zahlen zu "sparen". Kennt man sich einigermaßen aus, dann sollte man sich das aber besser wieder abgewöhnen. :mrgreen: Im Normalfall dürfte es keine Auswirkungen haben, aber für Profis in der Praxis irgendwann mächtig Ärger bedeuten.

willst du damit sagen, du legst einen trigger für _alle_ tabellen einer DB an ?


Gruss KH

[DeddyH]

Nicht einen Trigger, sondern einen Generator.

[khh]

Zitat:

Zitat von DeddyH

Nicht einen Trigger, sondern einen Generator.

ach soooo,
hab mich gerade gewundert wie das geht ;-)


naja einen Generator in allen Triggern zu verwenden, ist gar keine schlechte Idee.
Die erledigen ja eh alle die gleiche Arbeit.


Gruss KH

[mkinzler]

Dafür hast du dann einen Nummernkreis für alle deine Tabellen

[mjustin]

Zitat:

Zitat von mkinzler

Dafür hast du dann einen Nummernkreis für alle deine Tabellen

Das ist zum Beispiel dann vorteilhaft, wenn alle Entitäten im Programm in einer einfachen Persistenzschicht (O/R Mapper) verwaltet werden sollen, dann ist die ID aus der Datenbank immer auch als Key in der Persistenzschicht brauchbar, keine Kollisionsgefahr und sehr einfache Anlage von neuen Objekten mit eindeutiger ID.

[khh]

Zitat:

Zitat von mkinzler

Dafür hast du dann einen Nummernkreis für alle deine Tabellen

mh, stimmt, der merkt sich ja die Werte, wobei für ne einfache id kanns ja egal sein.


EDIT:

nee ist glaube ich doch keine so gute idee,
ich wäre mal auf die Ausführung von hansa gespannt, was für einen Ärger er da meint.


Gruss KH

[Hansa]

Zitat:

Zitat von mkinzler

...Amateure brauchen das gar nicht zu wissen :zwinker:

Yes indead, so isset. :mrgreen: Aber ganz unwichtig ist es nicht. Weil es im Thema um Trigger ging und nicht um Generatoren, wollte ich hier auch nicht weiter darauf eingehen, aber was solls :

Warum pro Table einen eigenen Generator ?
Das weiß der Kuckuck. :P Kommt wohl lediglich daher, dass immer von einem Generator/Trigger "Gespann" gesprochen wird. Das alleine schon suggeriert x Tabellen = x Generatoren. Ein theoretisches Argument wäre die Anzahl der Generatorenwerte.

Zitat:

Zitat von Firebird-Doku

Generatoren speichern und liefern 64-bit Integerwerte in allen Firebird-Versionen. Dies ergibt einen Wertebereich von:

-263 .. 263-1 oder -9,223,372,036,854,775,808 .. 9,223,372,036,854,775,807

Würde man also einen Generator mit Startwert 0 benutzen, um damit eine NUMERIC(18) oder BIGINT-Spalte zu befüllen, und man würde 1000 neue Datensätze pro Sekunde anlegen, dann würde es etwa 300 Millionen Jahre (!) dauern bevor der Generator überläuft. Da es eher unwahrscheinlich ist, dass die Menschheit dann noch auf diesem Planeten herumläuft (und immer noch Firebird-Datenbanken einsetzt), braucht man sich darüber also nicht wirklich Gedanken machen.

Reicht das als Info ? Hat noch einer ein Argument für ein solches Vorgehen, dann soll er es sagen. Mir fallen jetzt nur die Telekom-Verbindungsdaten ein (in Betracht kommen eigentlich nur maschinelle Inserts und keine manuellen), die eventuell mit einem Generator, der eine integer-ID bestückt Ärger kriegen könnten. Für die gäbe es dann eben Bigint.

Warum pro Table keinen eigenen Generator, sondern nur einen ?

Es geht um die bestmögliche referentielle Integrität der DB und zwar darum, diese auch langfristig zu sichern.

Bleiben wir mal bei der Telekom : angenommen die speichern die Verbindungsdaten in 10 Rechenzentren und in regelmäßigen Abständen sollen die Daten zentral gespeichert werden. Die dürfen sich natürlich nicht ins Gehege kommen. Die Rechenzentren haben jeweils einen Generator-Startwert von 0 dann 1.000.000.000.000.000 bis 9.000.000.000.000.000. Dürfte reichen und es ist sogar noch mehr Platz. Und jetzt ? Selbst wenn unterschiedliche Rechenzentren die Daten von ein und demselben Kunden erfassen und diese dann zusammengewürfelt werden, dann ist noch immer alles in Ordnung.

Würde man das anders machen, dann wären die IDs nicht mehr eindeutig zuzuordnen. Es wäre nicht mal ein permanenter Datenabgleich nötig. Und der Fragesteller braucht sich nur einmal den Namen des Generators zu merken. :zwinker:

P.S. wg. roter Kasten : die "Nummernkreise" sind da schon indirekt drin. Sollte es bei den 10 Rechenzentren gleiche Rechn.Nummern etc. geben und die Daten müssten erst später zusammengeführt werden, dann ist es ein leichtes einmalig eine 0..9 davorzuhängen und fertig. Die IDs müssen aber bleiben wie sie sind.

[mkinzler]

Wenn die Inhalte der Tabellen aber verschieden ist, stellt das kein Problem dar.

[Hansa]

Du willst das wohl nicht verstehen ? :mrgreen: Der Nutz-Inhalt der Tabellen (also der für das Programm gedachte) ist ziemlich egal, solange nur die DB-interne ID eindeutig ist. Und genau die sollte eben nicht manipuliert werden.

[Der Jan]

Ich glaube, dass geht langsam ins Philosophische :) Ich sehe einen wirklichen Sinn auch nur darin, wenn die Tabellen die gleiche Struktur haben. Ich hatte mal einen Fall, wo ein Kunde wollte, das in der DB Kundendaten pro Filiale in separaten Tabellen gespeichert werden. Da hab ich auch für diese Tabellen nur einen Generator verwendet, um später, z.B. bei einer Filialzusammenlegung, weniger Aufwand zu haben. Aber ansonsten bin ich halt auch nur Amateur ;)

[Elvis]

Du kannst dir das auch autom. für alle deine Tabellen erzeugen lassen:
Firebird-Script zur Erzeugung von AutoInc (inc. max Value)

[mkinzler]

Damit hast du dich auch als Amateur geoutet :stupid:

[alzaimar]

Es gibt natürlich Argumente FÜR einen eigenen Generator: Wenn ich wissen will, ob ein Datensatz aufgrund eines Rollbacks nicht gespeichert wurde, also eine 'Lücke' in der Sequenz ist, wäre das mit einem eigenen Generator für diese Tabelle einfach zu lösen. Ansonsten sprechen nur ästhetische Gründe für mehrere Generatoren (Und Bequemlichkeit bei der Erstellung des Schemas). Ob die Wahl (einer / mehrere) nun konkrete Rückschlüsse auf das Entwicklerniveau (Amateur/Profi) zulässt, sei mal dahingestellt.

[khh]

hallo zusammen,
ich danke euch für die ausführlichen Meinungen.



Gruss Kh

[Elvis]

Zitat:

Zitat von mkinzler

Damit hast du dich auch als Amateur geoutet :stupid:

Es gibt Leute, von denen es durchaus schmeichelnd ist, als Amateur bezeichnet zu werden. ;-)

IOW: Ich werde mich wohl kaum wegen Hansa in den Schlaf weinen *g*

Er hat da aber einen Punkt: Wenn man bigint (iow Int64) als key nutzt, dann kann man sehr wohl eine Sequence für ALLE Tabellen haben.
Das Problem ist aber, dass diese Art von "ObjectID" gar nicht sooo nützlich ist, wie man es anfangs vermutet.
Code, der den Type eines Objektes nicht mehr zur Identifizierung herannimmt, würde nicht mehr mit nicht-persistenten Objekten klar kommen. Oder nur sehr unintuitiv, und auf dem Wege wäre viel von dem Nutzen einer DB-globalen unique ID wieder aufgebraucht.