Fremdschlüssel bei Insert ermitteln

[monta]

Hallo, ich habe ein grundlegendes Problem, für umfangreiche Inserts über mehrere Tabellen.
Ich nutze die SP um einen neuen Datensatz in meiner Datenbank anzulegen.

Normalerweise waren das nur zwei drei Tabellen, bei einem neuen Projekt benötige ich aber insgesamt ca. 50 Tabellen, auf welche die daten verteilt werden.
Die Main-Table beinhaltet dabei die entsprechenden Fremdschlüssel zu den anderen Tabellen. Wenn ich nun einen kompletten Datensatz einfügen will, benötige ich ja alle Fremdschlüssel. Ich muss also für jede Tabelle testen, ob der Wert schon vorhanden ist, wenn ja, benötige ich dessen Primärschlüssel, wenn nicht, muss ich den Wert erstellen und den neuen Primäschlüssel ebenfalls zwischenspeichern.

Wenn ich dann alle Primärschlüssel hab, kann ich ja schließlich damit die Main-Table füttern.

Nun stelt sich aber die Frage, wie man dies realisieren kann, logisch ist es möglich, für alle tabellen die Abfrage inzuschreiben und den Wert zwischenzuspeichern, ungefähr so:

SQL-Code:

begin
  if (not exists (select id from filme
    where (filme.film = :XFILM) and (filme.idmag1 = :XMAG1)))
    then
    begin
      insert into filme
        (film, idmag1, idmag2, filmid, bemerkungen)
        values
        (:XFILM, :XMAG1, :XMAG2, :XFILMID, :XBEMERKUNGEN);
/*dann enthält ja der generator die entsprechende ID, auf welche ich zugreifen kann: gen_id(gen_filme_id, 0);*/
    end
    else
    begin
/*ansonsten Abfrage der ID*/
      select Id from filme
        where (filme.film = :XFILM) and (filme.idmag1 = :XMAG1)
        into :ID;
    end
   suspend;
end

Nur ist dies für insgesamt 50 Tabellen recht mühsam.
Weshalb ich es gerne etwas Schachteln würde, nur dafür fehlt mir gerade der Ansatz.

1. Eine Storedproc für die Unterabfrage - nur wie übergeb ich der als Parameter den entsprechenden Tabellennamen?
2. was fast besser wäre, eine unterfunction in der StoredProc, aber selbes Problem, wie erstellt man sie überhaupt und wie kann ich die Tabelle übergeben?
3. UDF würde sich wahrscheinlich eignen - hab ich aber keinerlei Ahnung von.
4. Alles manuell für jede Tabelle so wie oben?
5. Andere Methode?

[Hansa]

Zitat von monta:

..bei einem neuen Projekt benötige ich aber insgesamt ca. 50 Tabellen, auf welche die daten verteilt werden. Die Main-Table beinhaltet dabei die entsprechenden Fremdschlüssel zu den anderen Tabellen. Wenn ich nun einen kompletten Datensatz einfügen will, benötige ich ja alle Fremdschlüssel...

Ja und ? Das muss hierarchisch aufgebaut sein. Kein Fremdschlüssel -> kein Eintrag in DB.

[monta]

Zitat von Hansa:

Ja und ? Das muss hierarchisch aufgebaut sein. Kein Fremdschlüssel -> kein Eintrag in DB.

Das versteh ich jetzt nicht ganz, klar, wenn kein Fremdschlüssel da ist, gibts bei den Abrufen auch keinen Wert für das entsprechende Feld, bzw. es verweist halt auf NULL.
Aber das Problem ist doch, wenn ich meine gesamten Werte an die StoredProc übergebe, muss ich diese doch bei den Inserts auf die Tabellen aufteilen und dazu brauch ich ja für 50 Tabellen 50 Abfragen, ob der Wert existiert.

Und nun ist ja die Frage, wie man diese 50Abfragen möglichst leicht realisiert ohne sie in hunderte Zeilen alle einzeln aufzulisten.

Daher ja auch die Frage, ob man beispielsweise einer zweiten StoredProc eien Tabellennamen übergeben kann, bzw. die Tests in ner Unterprozedur kapselt.

Oder steh ich irgendwie auf der Leitung?

[mkinzler]

Zitat:

Daher ja auch die Frage, ob man beispielsweise einer zweiten StoredProc eien Tabellennamen übergeben kann, bzw. die Tests in ner Unterprozedur kapselt.

Nein der Tabellennamen ist nicht parametrisierbar. Du könntest diese Abfragen höchstens in Client (per Schleife) machen.

[Hansa]

Er geht wohl falsch vor. 8) Das Problem dürfte tiefer liegen. Um das jedoch zu analyysieren bräuchte man die komplette Definition der betroffenenen Tables. Insbeseondere der unique Keys. Meine Glaskugel hat nämlich folgendes gemeint : es könnte ein zusammengesetzter unique Key existieren, der in einem Feld einen NULL - Wert hat. Insofern wäre der ganze Wert des Keys = NULL. => duplicate key, also kein fehlerfreies INSERT. Man merke : ein Feld = NULL, alle anderen haben definierten Wert, das ergibt trotzdem NULL, also undefiniert. Weiterhin dürfte kein passender BI-Trigger vorhanden sein, der eventuell die NULL-Felder mit einem definierten Wert vorbesetzt. Usw. Bei 50 Tabellen muss das aber klar sein, was zu tun ist. Insofern musst Du dir dringend mal den Firebird Null-Guide durchlesen (auf FB Homepage suchen). Das ist echt wichtig !

[mkinzler]

@hansa: Wenn ich ihn richtig verstehe, handelt es sich um eine Datenbankschema mit einem sehr hohen Normalisierungsgrad. Wird nun eine Neuer "Datensatz" angelegt, muß der folgerichtig zerlegt werden und führt zu Inserts in vielen Tabellen, wobei vorher überprüft werden muß, ob der entsprechende Wert in dieser Tabelle schon existiert.

kleines Beispiel:
DS 1. Normalform:
Name, Vorname, Vorname_Partner, Vorname_Kind1, Vorname_Kind2, Str, Plz, Ort, ..., Telefon, Telefon_Mobil, ...
Müller, Hans, Berta, Klaus, Susi, ...
muß in höher normalisiertes Datenbankschema überführt werden:

Person:
ID, Name, Vorname
1, Müller, Hans
2, Müller, Berta
3, Müller, Klaus
4, Müller, Susi

Adresse:
ID, Str, Plz, Ort
1, Hauptstr, ...

KommArt:
ID, Bez
1, Telefon_privat
2, Telefon_mobil
3, Fax

Kommadr:
ID, Art, Wert
1, 1, ...
2, 3, ...

BezArt:
1, Ehepartner
2, Kind

Beziehung:
ID, Art, Von, Zu
1, 1, 1, 2
2, 1, 2, 1
3, 2, 3, 1
4, 2, 3, 2
...

[monta]

Zitat von Hansa:

Meine Glaskugel hat nämlich folgendes gemeint : es könnte ein zusammengesetzter unique Key existieren, der in einem Feld einen NULL - Wert hat. Insofern wäre der ganze Wert des Keys = NULL. => duplicate key, also kein fehlerfreies INSERT.

Oh, da hat dich deine Glaskugel getäuscht
Nein im Ernst, ich verwende keine Zusammengesetzten Schlüssel. Sondern jede Tabelle hat ihren Primärschlüssel, welcher über Trigger und Generator automatisch beim Insert gesetzt wird, und nur der gilt.

Zitat von mkinzler:

@hansa: Wenn ich ihn richtig verstehe, handelt es sich um eine Datenbankschema mit einem sehr hohen Normalisierungsgrad. Wird nun eine Neuer "Datensatz" angelegt, muß der folgerichtig zerlegt werden und führt zu Inserts in vielen Tabellen, wobei vorher überprüft werden muß, ob der entsprechende Wert in dieser Tabelle schon existiert.

Genau so ist es. Ich dachte eben, das man dieses Zerlegen etwas rationalisieren kann, was sich ja aber wohl damit erledigt hat:

Zitat von mkinzler:

Nein der Tabellennamen ist nicht parametrisierbar. Du könntest diese Abfragen höchstens in Client (per Schleife) machen.

Aber irgendwie ist es schon recht unpraktisch, das Tabellen nicht als Funktionsparameter in der datenbank übergeben werden können . Aber lässt sich nichts machen, da muss ichs halt doch tabellenweise aufschreiben - das hat man nun von einem möglichst Vorbildhaften Datenbankschema
Im Client möchte ichs nicht machen, um dort möglichst frei zu sein, das der nur die Rohdaten an die DB übergibt und sich um den Rest nicht zu kümmern braucht.