Feldänderugnen im Trigger Prüfen Firebird

[Pro_RJ]

Ja das ist richtig.
Aber dafür müsste das Datenbankdesign für diesen einzelnen Kunden speziell angepasst werden.
Unsere Philosophie ist eigentlich jeder Kunde bekommt das gleiche Datenbankdesign und das gleiche Programm. Alle "Spezialanpassungen" für die einzelnen Kunden werden zentral vom Programm gesteuert.So das ob wohl jeder Kunde eigene Anpassungen hat nutzen alle exakt das gleiche.

[mkinzler]

Vielleicht wäre die normalisierte Db eine Option für alle Kunden.

[Pro_RJ]

Ja ist auch richtig.
Nur ein Paar Eckdaten :
ca: 100 Tabellen
3500 Felder
fast 500.000 Zeile QuellCode.

Pro : - Geschwindigkeitssteigerung
- geringere Datenbankgröße

Kontra : - ein riesen Umbau des Quelltextes.
- Änderung von alle Auswertungen/Druckformularen
- auf Grund der emormen Änderungen eine extrem große Fehleranfälligkeit.
- Es müsste per Update bei sämtlichen Kunden die Datenbank vom Programm aus neu Aufgebaut werden und dabei dürfen keinerlei Einstellungen,
Daten verlohren gehen
- Es wäre ein Riesen Kosten und Zeit aufwand.

Das Problem ist das die Datenbank seit nun mehr als 8 Jahren gepflegt und erweitert wird.
Wenn man jetzt an einem neuen Programm mit neuer Datenbank arbeitet bin auch absolut dafür sich vorher gedanken über das Datenbankdesign zu machen.
Und diese Datenbank soweit wie möglich zu normalisieren.
Nur ein bestehndes Programm mit bestehenden Datenbank nachträglich zu ändern ist annähern un möglich.Da dies einer Neuentwicklung gleich kommt.
Das ist auch der Grund dafür das ich an der Datenbank selber nicht viel machen kann.Bzw. sie nicht so Grundlegend ändern kann/darf.

[alex517]

Normalisierung wäre eigentlich der richtige Weg..
Ich hätte aber noch eine View-Variante die über einen Generator (OPT$USER) umschaltbar ist.

alex

[Pro_RJ]

Dankeschöööön ,
ich probiere es glich mal aus