Dependencies für Generatoren ermitteln

[tsteinmaurer]

Mir erschließt sich nicht ganz, warum man sich noch mit InterBase 6 abgibt, womöglich die Open Source Variante, die ein Rattennest an Bugs darstellt. Aber ich denke die Diskussion hatten wir in diesem Forum schon ein paarmal. :-D

[Perlsau]

Zitat:

Zitat von RSE (Beitrag 1228526)

@Perlsau:
Wenn 20 Stunden vergangen sind, bedeutet das mitnichten, dass ich 20 Stunden in die Lösung dieses Problems investiert habe.

Könntest du mir zeigen, wo ich behauptet hätte, du habest 20 Stunden oder auch nur 10 Stunden "in die Lösung dieses Problems investiert"? Denn eigentlich dachte ich lediglich geschrieben zu haben: "... nach gut 10 Stunden, noch immer nicht gelöst." :roll:

Nachtrag: Ja, da weiß er nun nichts mehr, der Herr RSE ...

[Hansa]

Zitat:

Zitat von RSE (Beitrag 1228526)

In unserer Firma gibt es Projekte (mehrere pro Woche), die jeweils ihre eigenen Tabellen etc. benötigen. Nach einiger Zeit (wenn die 2GB-Grenze von IB6 naht) werden alte Projekttabellen etc. entsorgt. In Einzelfällen entstehen auch Abhängigkeiten zwischen Projekten, und hier liegt die potenzielle Gefahr.

Jetzt mal mit Verlaub gesagt : wer hat diesen Unsinn zu verantworten ? :shock: 1. Mehrere Projekte pro Woche. 2. Jedes Projekt braucht seine eigenen Tabellen ? 3. 2 GB Grenze ist wichtig, bzw. diese Grenze wird schon mal erreicht ? Ist Dir überhaupt klar, was Projekt heisst ? Das ist ein (Haupt-)Programm. welches einen gewissen Datenbestand hat. Vielleicht gehören zu diesem "Projekt" auch noch einige Tools, Zusatzprogramme etc., wobei allerdings alles auf gemeinsamem Datenbestand aufbaut. Nennen wir das ganze dann eben "Projekt".

Jetzt erkläre mir mal, inwiefern da andauernd Tabellen angelegt, "entsorgt" werden müssen usw. ? Wenn wochenlang jede Woche mehrere Projekte neu angelegt werden, das wäre dann wohl 3-stellige Projektanzahl. Wird da etwa jede benötigte Tabelle in ein und dieselbe Datenbank gespeichert ? Das würde einiges erklären (auch die vielen Generatoren). 8-) Im Zusammenhang mit IB 6.1 deutet da wirklich einiges auf eine gehörige Portion Beratungsresistenz hin. :P Von denen die hier geantwortet haben ist keiner, der nicht weiss (und zwar ziemlich genau), von was er spricht ! "Redesign" ist da eher noch harmlos. :mrgreen:

[Blup]

Da das böse Wort "Redesign" nun schon gefallen ist, wozu benötigt ihr für jede Tabelle einen Generator?
Einer genügt für die ganze Datenbank (Spezialfälle mal ausgenommen).

[RSE]

Die ganze Geschichte, warum wir noch mit IB6.1 arbeiten und warum unsere DB so designt ist, wie sie ist, ist nicht auf meinem Mist gewachsen. Da diese Fragen hier nicht zur Diskussion stehen, werde ich sie hier auch weder verteidigen noch euch zustimmen. Ich spreche euch keine Kompetenz ab, aber um die Qualität einer Designentscheidung beurteilen zu können, sollte man schon wissen um was es geht - dann erscheint da nämlich einiges in anderem Licht, nicht alles ist Standardfall. Bevor weitere Kommentare in diese Richtung kommen: Ich werde nicht weiter darauf eingehen, da ich keine Lust habe, in jedem meiner Threads unsere gesamte Programmstruktur incl. Hintergrundinfos und Zukunftsplänen offenzulegen.

@Perlsau:
Dann hatte ich dich da offenbar missverstanden. Sorry dafür.

[hstreicher]

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

[QuickAndDirty]

Wir halten die Struktur der Datenbank vollständig in einer Konfigurationsdatei in einem datenbankneutralen Format vor.
Beim Anlegen von Autoinc Feldern, werden dann automatisch Trigger und der dazugehörige Generator angelegt.
Wenn man die Datenbank reorganisiert, werden alle Daten in temporäre Tabellen kopiert alle Trigger, Schlüssel, Generatoren und Tabellen werden gelöscht.
Die Datenbank wird aus den Strukturdaten in der Konfigurationsdatei wiederhergestellt und der Inhalt der temporären Tabellen in die neu angelegten Tabellen übertragen.

Wenn du also DB-Modell-Informationen hättest, könntest du dich ziemlich leicht aller unnötigen Generatoren entledigen.
Da man sowas eigentlich sowie so dokumentiert braucht, würde ich mich daran machen, sowas in maschienenlesbarer Form anzufertigen.

[Blup]

Zitat:

Zitat von hstreicher (Beitrag 1228658)

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