Stimmt, das ist nur eine Beschränkung für dieses Beispiel :) Die Tabellen sind in der Tat viel größer und ich will nur eine temp. Migration machen. Die Annahme, das STR_Name nur 1 x als Typ oben zu einer FKLID gehört, ist in meinem Beispiel zur Zeit korrekt, für die Zukunft ist es aber direkt so ausgelegt, dass die Tabelle 2 auch vom Typ oben zu einem STR_Namen mehrere FKLIDs haben kann. Das ist schon korrekt so, nur momentan kann ich mich drauf verlassen, dass dies eben nicht der Fall ist. Ich weiß, dass es nicht so ist :)
Achso, falls Tabelle 2 einen Namen mit dem Typ oben und unten hat, dann sind dies unterschiedliche FKLIDs.
Ziel Tabelle 1
Code: Alles auswählen
ID STR_AUTOR L_BEREICH STR_TEXT
1 A 5 XYZ
2 B 2 XYZ
3 C XYZ
4 A 5 XYZ
5 C XYZ
6 A 5 XYZ
7 B 2 XYZ
8 B 2 XYZ
9 B 2 XYZ
10 C XYZ
C hätte in diesem Beispiel keine L_Bereich, da er in Tabelle 2 keinen Eintrag mit dem Typ oben hat. Eigentlich ist mein Beispiel hier schon falsch, da alle STR_Autoren A, B, C mindestens einmal den Typ oben haben in Tabelle 2. Daher muss Eintrag 4 in Tabelle 2 ebenfalls den Typ oben haben. Dann würde in Tabelle 1 für Autor C im L_Bereich eine 1 stehen. Sorry für die Verwirrung. Hier also die korrekten Tabellen:
Tabelle1
Code: Alles auswählen
ID STR_AUTOR L_BEREICH STR_TEXT
1 A XYZ
2 B XYZ
3 C XYZ
4 A XYZ
5 C XYZ
6 A XYZ
7 B XYZ
8 B XYZ
9 B XYZ
10 C XYZ
Tabelle 2
Code: Alles auswählen
ID FKLID STR_Name STR_TYP
1 5 A oben
2 2 B unten
3 5 A oben
4 1 C oben
5 4 D oben
6 33 E oben
7 6 D unten
8 7 D unten
Ziel Tabelle 1
Code: Alles auswählen
ID STR_AUTOR L_BEREICH STR_TEXT
1 A 5 XYZ
2 B 2 XYZ
3 C 1 XYZ
4 A 5 XYZ
5 C 1 XYZ
6 A 5 XYZ
7 B 2 XYZ
8 B 2 XYZ
9 B 2 XYZ
10 C 1 XYZ