Hallo Raketenwilli,
ja ok, kann man so machen. Wenn man Autoinkrement-IDs für jede Table verwendet. Das ist in meinen DBs öfter mal nicht der Fall, die sind oftmals anders geschlüsselt und haben die ID ihrer Parent-Row zusammen mit einem weiteren Attribut als Key. Die muss ich dann auch beim Neuanlegen vorbelegen, sonst kriege ich die Assoziation nicht hin.
Einen solchen zusammengesetzten Schlüssel als Clustering Key zu verwenden hat durchaus Performance-Vorteile, das spart dem Kopf der Festplatte im DB-Server ggf. einige Meter Flugweg. Wenn X die ID der Parent-Row ist und der composite key das Tupel (X, Z) ist, dann sind alle abhängigen Rows zum parent key X auf der Festplatte beisammen, wenn (X,Z) der Clustering Key ist und lassen sich schnell lesen. Wenn X und Z nur Fremdschlüssel sind, es eine eigene ID gibt und ich einen unique index auf (X,Z) lege, kann es durchaus passieren, dass die benötigten Rows für X kreuz und quer in der Tablespace-Datei verteilt sind.
Und ja, diese Performancegewinne sind für mich relevant und spürbar.
Rolf
sumpsi - posui - obstruxi