nicht angemeldet
Hi,
das halte ich für kritisch. ich würde grundsätzlich niemals, irgendwelche fachlichkeit in einem PK bringen. das kann zu probleme führen, diem an heute noch nicht absieht. benutze einfach immer einen künstlichen schlüssel und gut ist.
Das ist eine sehr umstrittenes Thema ;-)
nun, ich für meinen fall finde, da gibt es wenig zu streiten. ich habe bisher noch keinen nachteil von künstlichen schlüseln kennengelernt, aber nachteile von sprechenden schlüsseln. aber sicherlich ist es nur meine meinung und man kann darüber streiten, wenn man will, muss man aber nicht. ;-)
Wie wäre es mit wesentlich mehr Joins wenn man eigentlich nur den "Wert" des PK braucht? So teuer wie joins sind, kann das durchaus signifikant sein (Insbesondere wenn die referenzierten Tupel sehr groß sind).
Nicht falsch verstehen - ich bin prinzipiell auch ein Freund (Nein, Ben, kein Kommentar) von Surrogate Keys. Aber imho sollte man es pragmatisch sehen.
oder wäre es noch effizienter, wenn ich einen Index so anlege, dass ich sage, dass "Index XYZ aus PK / TabA, PK / TabB, PK / TabB, PK / TabC" besteht, also ein zusammengesetzter Index aus den Primärschlüsseln von 4 Einzeltabellen sozusagen?
habe ich eine entwicklung verpasst, du kannst einen zusammengesetzen index aus verschiedenen tabellen erzeugen ? so recht will ich mir das nicht vorstellen....
Ich nehme an, er hat eine Tabelle in der er suchen möchte, die foreign keys zu den 4 Lookup Tabellen enthällt.
das habe ich auch erst gedacht, aber er hat recht explizit die verschiedenen tabellennamen angegeben, nämliche die PK aus TabA, TabB.....
Ich hoffe einfach, dass du ihn falsch verstehst ;-)
Grüße,
Andres Freund