Dependencies für Generatoren ermitteln

[Blup]

Zitat von hstreicher:

Autoincrement Wert werden bei Interbase / Firebird über Generatoren und Trigger erzeugt,
also JA man braucht ne menge davon mit den beiden Datenbanken

Ich arbeite seit mindestens 10 Jahren mit Interbase/Firebird und kann dir berichten das zumindest in den Datenbanken unserer Kunden so bis 10GB ein 32-Bit Generator für alle Tabellen genügt. Ein Trigger für jede Tabelle, aber alle können den selben Generator nutzen.

[Hansa]

Genau so siehts aus. Ausnahme : Online-verarbeitete Daten, d.h., wenn z.B. pro Sekunde 100 eingehende Bestellungen anfallen mit jeweils mehreren Positionen. Von Hand lässt sich ein Generatorwert jedenfalls kaum komplett füllen (auch in Jahren nicht). Hätte man sich das mal vorher überlegt, oder würde eben jetzt handeln, dann wäre das Problem gar nicht erst aufgetaucht.

[IBExpert]

wenn du nur die Referenzen deiner Steinzeit DB wissen willst, dann mach es dir doch einfach und mache ein Backup und ein Restore unter unter FB2.X und schau dann einfach mit den SQLs in die DB. So holt sich übrigens IBExpert Dependencies für Generatoren (kann man in IBExpert sehen, wenn man vorm Öffnen der Seite Dependecies im Menü Tools den SQL Monitor anwirft (in diesem Beispiel hieß der Generator ID).

select D1.RDB$DEPENDENT_NAME, D1.RDB$FIELD_NAME, D1.RDB$DEPENDENT_TYPE, R1.rdb$relation_name
from RDB$DEPENDENCIES D1
left join rdb$relations r1 on ((D1.RDB$DEPENDENT_NAME = r1.rdb$relation_name) and (not (r1.Rdb$View_Blr is null)))
where (D1.RDB$DEPENDED_ON_TYPE = 14)
and (D1.RDB$DEPENDENT_TYPE <> 3)
and (D1.RDB$DEPENDED_ON_NAME = 'ID')
union
select distinct f2.rdb$relation_name, d2.rdb$field_name, d2.rdb$dependent_type, r2.rdb$relation_name
from rdb$dependencies d2, rdb$relation_fields f2
left join rdb$relations r2 on ((f2.rdb$relation_name = r2.rdb$relation_name) and (not (r2.Rdb$View_Blr is null)))
where (d2.rdb$dependent_type = 3) and
(d2.rdb$dependent_name = f2.rdb$field_source)
and (d2.rdb$depended_on_name = 'ID')
order by 1, 2

[Furtbichler]

Zitat von Blup:

Ich arbeite seit mindestens 10 Jahren mit Interbase/Firebird und kann dir berichten das zumindest in den Datenbanken unserer Kunden so bis 10GB ein 32-Bit Generator für alle Tabellen genügt. Ein Trigger für jede Tabelle, aber alle können den selben Generator nutzen.

Ich habe eine FB mit einem Generator bei einer Messdatenerfassung im Einsatz und muss leider feststellen, das bei ca. 600 Messwerten pro Sekunde FB zwar locker mitkommt, aber das Ganze dann doch etwas knapp wird. Ich habe auf den PK per ID hier verzichtet.

Es kommt -wer hätte das gedacht- immer auf den Einsatzzweck an. Ein Durchrechnen des Szenarios über alle Unbekannten, wie z.B. Durchsatz, Spitzensatz, #IDs, Speicher sollte immer vor dem DB-Design erfolgen.

[mkinzler]

Bei BigInt sollte da genügend Luft nach oben sein

[Furtbichler]

Zitat von mkinzler:

Bei BigInt sollte da genügend Luft nach oben sein

Natürlich, ich wollte nur anmerken, das 4 Milliarden Datensätze nicht notwendigerweise ausreichen. Es gibt Datenbanken, da kommen und gehen die Daten (wie bei der Messadatendatenbank) und da geht das dann recht schnell. BigInt sollte dann aber doch reichen, bis die Garantiezeit beendet ist.

[mkinzler]

Der BigInt von Firebird hat 64 Bit (vorzeichenlos). Das wären bei 600 Werte pro Sekunde ca. 975 Mio Jahre! Ich glaube länger hält keine Garantie!

[RSE]

Sorry, ich habe keine Benachrichtigungen mehr bekommen, werde das mal überprüfen müssen...

@ User IBExpert:
Ich glaube ein Restore unserer IB6.1 DB unter Firebird 2.x würde diverse andere Fehler bringen. Wir verwenden z.B. START und STOP als Feldbezeichner und das sind doch jetzt reservierte Worte. Von daher ist das eine gute Idee, die recht schnell alle Dependencies aufzeigen würde, wenn man nicht diverse Fehler dabei korrigieren müsste.