Feldänderugnen im Trigger Prüfen Firebird

[Pro_RJ]

Huhu,
Also ich habe folgende Aufgabe :
Ich habe eine Tabelle Adressen wo ich pro User Adressen Speichern und verwalten kann.

Es sollen mehrere User den gleichen Adressstamm nutzen möchten.
Bsp.: User 1,2,3.
Wenn jetzt der User1 eine Adresse anlegt
AdressNr = 1,
Name1 = 'aaaa'
Vorname = 'bbbbb'.....

soll automatisch auf User2 und User3 die gleiche Adresse mit gleicher Adressnr,Vorname,name1..... angelegt werden.
So bis hierher kein Problem.

Wenn jetzt der User2 Name1 ändert, soll auch Automatisch der Name1 auf den User1 und User3 geändert werden.

Jetzt die Interessante Frage wie kann man sowas realisieren
Ich hatte 2 grundsätzliche Überlegungen :
1. in Echtzeit über einen After Update Trigger like

Code:

  
  if (Old.Name1 <> New.Name1) then Update Adressen set Name1 = New.Name1 where AdressNr = New.AdressNr and ID <> New.ID;
  if (Old.Name2 <> New.Name2) then Update Adressen set Name2 = New.Name2 where AdressNr = New.AdressNr and ID <> New.ID;

Das Problem ist, das die Tabelle aus ca. 100 Feldern besteht die alle überwacht werden sollen.
Wenn ich den Trigger über den Beschriebenen weg aufbaue wir der Trigger Riesig und unüberwachbar und vor allem nicht pflegbar.
Denn wenn jetzt ein neues Feld hinzu kommt muss ich daran denken es in diesen Trigger mit einzupflegen.

Meine 2.Überlegung wäre eine Gleichschaltung ca alle 5 min.
Dafür müsste ich mir aber irgendwie speichern, welches Feld auf welchem User jetzt aktuell ist.
Was an sich ja über eine Tabelle sehr einfach zu realisieren wäre.
das Problem ist, der Trigger auch wieder so aussehen würde.

Code:

  
  if (Old.Name1 <> New.Name1) then execute procedure SetzeAenderunfskKZ('Name1',New.Zaehler);
  if (Old.Name2 <> New.Name2) then execute procedure SetzeAenderunfskKZ('Name2',New.Zaehler);
....

nur hier bin ich wieder an gleich Problem wie oben

gibt es eine Möglichkeit einen Trigger nach folgendem Muster aufzubauen.

Code:

declare variable FLDName VarChar(25);
begin
  For
  Select RF.RDB$Field_Name
  from RDB$Relation_FIelds RF
  where Upper(RF.RDB$Relation_Name) = 'ADRESSEN'
  into :FLDName
  do
  Begin
    if (Old.FLDName <> New.FLDName) then execute procedure SetzeAenderunfskKZ(:FLDName,New.Zaehler);
  end
end

nur geht sowas überhabt?
Bzw. wie würdet ihr dieses Problem angehen?

mfg Jens

[mkinzler]

Man könnte auch für jedes Feld einen Trigger anlegen.
Eine Normalisierung des Schemas wäre aber auch ratsam.

[Pro_RJ]

Naja dann habe ich ja wieder das gleich Problem.
An der Datenbankstruktur kann ich leider nicht wirklich was ändern, da diese fest vorgegeben ist.

[mkinzler]

Zitat:

Naja dann habe ich ja wieder das gleich Problem.

Wäre aber übersichtlicher.

[dfried]

Ich verstehe den Sinn der ganzen Aktion noch nicht ganz, da durch diese Trigger eh alle User nachher alle Adresen gleich haben wieso dann die Adressen mehrfach (pro User) speichern?
Oder gibt es auch Konstellationen in denen ein USer explizit verhindern kann, dass die von Ihm eingegebene Adresse auch alle anderen User automatisch (über den Trigger) bekommen?

[hoika]

Hallo,

schreib dir doch eine Routine,
die den "unübersichtlichen" Trigger selber erzeugt,
indem die Tabelle analysiert wird (Feldnamen).

Die Methode rufst du auf, nachdem neue Felder erzeugt worden sind.


Heiko

[Pro_RJ]

Also das Programm und die Datenbank sind so entwickelt das jeder User ganz für sich alleine arbeitet.
Jetzt ist ein Anwender dazu gekommen, der zwar mit meheren Usern aberbeitet aber einen einheitlichen Adresstamm haben möchte.
Da es aufwändiger ist das gesamte Programm umzubauen wollte ich es über diesen weg realisieren.

[mkinzler]

Oder normalisiere die Tabellen und simuliere das Excel-Datenbank-Schema per View/SP

[Pro_RJ]

Ich darf aber weder an der Datenbankstruktur noch an Statements im Programm etwas ändern.
Im Prinzip darf ich nur die Daten duplezieren.

[dfried]

Würde wie mkinzler das vorschlägt die Tabelle durch einen gleichnamigen View ersetzen (die Tabelle natürlich vorher umenennen), dann ist das für das Programm transparent, d.h. es bekommt von der Änderung gar nix mit. Schwierig wird allerdings das Insert bzw. Update der Daten, da der View vermutlich nicht aupdatefähig sein wird.
Unter Oracle würde ich das über einen "Instead of"-Trigger realisieren, weiss jetzt aber leider nicht auswendig, ob Firebird das auch kann.