nicht angemeldet
yo,
Ich habe bis jetzt noch nie verstanden, warum man in einer Tabelle, in der eine Spalte existiert, die einen Datensatz bereits eindeutig identifiziert (was ja die Aufgabe eines Primär-Schlüssels sein soll), noch zusätzlich eine zweite Spalte anlegen soll, deren Wert dann, so vermute ich mal, per Sequenz oder AutoID oder wie auch immer erzeugt wird.
ja hat es, wobei es nicht darum geht, mehr als einen unique und nicht zu vergessen not null spalte zu haben, sondern darum, keine "inhalte" in den pk zu legen. das problem dabei ist, dass sich die inhalte im laufe der zeit ändern können und man dann nicht nur den sprechenden schlüssel ändern muss, sondern aller wahrschenilichkeit auch alle anderen spalten, wo er als fremdschlüssel verwendet wird.
ein beispiel dafür wäre eine autonummer. diese ist sicherlich unique und not null, erfüllt also beide kritereien eines pk. aber sie kann sich für eine und dasselbe auto im laufe der zeit ändern. und das wäre schlecht, wohingegen eine künstliche spalte keine probleme damit hätte.
abgesehen von allfälligen Performance-Aspekten, die ich so einfach aus der Hüfte aber nicht beantworten könnte.
die performance von unterabfragen hat einen schlechten ruf. in der praxis sind sie aber in regel viel schneller, besonders im vergleich zu UNION, der meiner meinung nach in diesem fall nicht nur unflexibler ist, sondern auch eine sortierung der gesamten ergebnismenge nach sich zieht, da er distincte werte auschließt, mal davon abgesehen, ob das überhaupt gewollt ist.
Ilja