firebird Trigger

[mkinzler]

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

[khh]

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

...Amateure brauchen das gar nicht zu wissen

Yes indead, so isset. 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. 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 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.

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