@RED-BARON
Ich kann dir jetzt keinen Fall aus der Praxis sagen wo ich das gemacht oder dringend gebraucht hätte. Grundsätzlich kann es diese Fälle aber sehrwohl geben.
Erstmal ist fraglich ob man es überhaupt immer (oder so gut wie immer) einen bestehenden Key gibt. Dann, wenn es so einen Key gibt, ist fraglich ob man ihn übernehmen kann bzw. will. Wenn man z.B. Daten aus mehreren Quellen importiert kann man den Key oft nicht 1:1 übernehmen. Natürlich kann man den Key erweitern indem man ihn um z.B. eine Quellen-ID erweitert. Will man aber nicht unbedingt immer - zumindest nicht als Primary Key. Was dann gleich der nächste Punkt ist: was wenn der Key mehrspaltig ist, vielleicht gar aus ein paar String-Feldern besteht? Sowas will man oft nicht als Primary Key haben. Also muss ein Surrogate Key her. Wobei man da natürlich als Workaround die automatisch generierten Surrogate-Keys wieder aus der Tabelle raus-selecten kann, indem man auf den übernommenen Candidate-Key filtert. Wenn der Candidate-Key mehrspaltig ist, und man es so richtig performant haben will, wird das allerdings auch wieder etwas kompliziert.
Und dann bleiben wie gesagt die Fälle wo man wirklich keinen Candidate-Key hat.
Und brauchen tut man das dann immer da, wo man abhängige Datensätze mit importieren möchte. Also wo man irgendeine Kopftabelle und Detailtabellen hat, und Daten in beide importieren muss. Denn um die Detailtabellen zu befüllen braucht man logischerweise den Key aus der Kopftabelle.
