Dependencies für Generatoren ermitteln

[Perlsau]

Zitat von RSE:

@Perlsau: Das wäre mein zweiter Lösungsansatz geworden, aber da die Aufgabe nicht sooo oft vorkommt, macht meine Idee weniger Aufwand

Nicht für untug äh ungut, aber diesbezüglich hege ich doch leise Zweifel: Du beschäftigst dich meines Wissens nach seit 14.09.2013 15:56 Uhr damit, und wie ich sehe, ist dein Problem am 15.09.2013 um 02:20, also nach gut 10 Stunden, noch immer nicht gelöst. Da würde eine kleine Anwendung, geschrieben in sagen wir mal großzügig allerhöchstens 1 bis 2 Stunden, doch wesentlich weniger Aufwand erfordern, oder nicht?

Noch etwas: Offenbar arbeiten mehrere Leute in eurer Firma mit und an dieser Interbase-Datenbank. Wäre es da nicht am einfachsten, diese Leute zu fragen, ob sie irgend welche Generatoren erstellt und welche davon sie noch in Verwendung haben? Wenn es mehr als eine DP-Application gibt, die auf die Datenbank zugreift, durchforstet man die ebenfalls nach Generatorenbenutzung. So hat man schon mal eine Liste von Generatoren, die keinesfalls gelöscht werden dürfen. Dann würde ich mich den Generatoren widmen, die in der Datenbank notwendige Indexwerte (z.b. sämtliche PK-Generatoren) erzeugen bzw. erhöhen und diese ebenfalls der Liste hinzufügen. Und dann würde ich alles löschen – falls dir nicht noch weitere schützenswerte Kriterien einfallen –, was nicht auf der Liste steht – selbstverständlich mit vorangegangenem Backup. Dieses gut aufbewahren für den Fall, daß in ein zwei Wochen der eine oder andere angerannt kommt und sich beschwert, daß sein Generator nicht mehr funktioniert ...

[haentschman]

Moin...
Ich finde, daß dein Vorhaben mit Aufräumen nix mehr zu tun hat. Das ist schon ein Redesign. Ich denke, daß du es dir schwer machst.
Vorschlag:
1. Design der neuen DB
2. ggf. die Anwendung auf das bessere Design anpassen.
3. mit IBExpert ein Differenzscript zur alten DB erstellen lassen.
4. ggf. alte DB damit updaten.

...funktioniert bestens.

[tsteinmaurer]

Folgende Abfrage in Firebird gibt dir eine Liste an Objekten, die Generatoren referenzieren:

Code:

select * from rdb$dependencies where rdb$depended_on_type = 14

Solltest du wirklich InterBase 6 einsetzen, dann kann es sein, dass dies ev. nicht verläßlich funktioniert, weil es bei InterBase 6 vorkommen konnte, dass die Abhängigkeiten in der RDB$DEPENDENCIES nicht sauber eingetragen wurden. Aber ein Versuch wäre es wert.

[RSE]

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.

@Hansa:
Damit fällt also die Suche nach nie genutzten Generatoren (mit Nullwert) nicht in das aktuelle Problem.

@Perlsau:
Wenn 20 Stunden vergangen sind, bedeutet das mitnichten, dass ich 20 Stunden in die Lösung dieses Problems investiert habe. Manchmal ist es sinnvoll, mehrere Aufgaben nach Problemen zu durchdenken, bevor man die erste umsetzt, um Zeit für Forenanfragen zu haben. Dies ist so ein Fall.

Dass ich zusätzlich zur DB auch die Anwendung, die diese benutzt durchsuchen muss, ist klar. Diese Anwendungssuche ist aber ebenfalls nicht Teil dieses Threads, da sie in meinem Fall kein Problem darstellt, da die betroffenen Projekte längst inaktiv sind.

PK-Generatoren werden in IB6 mittels Triggern umgesetzt, welche in meinem Ansatz abgedeckt sind.

Backups machen wir mehrmals täglich, da ist also eine gute Auswahl vorhanden. Eines wird speziell von direkt vor dem Aufräumen vorgehalten.

@haentschman:
Wie du siehst, hat das Ganze in meinem Fall nichts mit einem Redesign zu tun.

@tsteinmaurer:
Wie in meinem ersten Beitrag geschrieben, führt IB6 keine Dependencies für Generatoren. Das funktioniert leider erst ab Firebird.


Bis hier also keine Neuerungen an meinem Lösungsansatz. Trotzdem danke für eure Gedanken.

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

[Perlsau]

Zitat von RSE:

@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."

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

[Hansa]

Zitat von RSE:

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 ? 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). Im Zusammenhang mit IB 6.1 deutet da wirklich einiges auf eine gehörige Portion Beratungsresistenz hin. 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.

[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