nicht angemeldet
yo,
Kann man da nicht die Kombination Primärschlüssel,FremdSchlüssel,Fremdschlüssel machen?
sicherlich ist das auch eine möglichkeit. aber zum einem soll deine seite ja lehren, sprich man sollte beide möglichkeiten kennen, um sich für die in einem speziellen fall optimale lösung entscheiden zu können.
zum anderen macht es sinn, den primary key über die beiden spalten zu bilden. erstens ist es eine spalte weniger und zweitens sollte man sowieso aus gründen der integrität einen unique und not null constraint über die beiden spalten legen. und die beiden sind nun mal die eigenschaften eines pk schlüssels.
Kennst du konkret ein Beispiel, wo sowas mal aufgetreten ist. Ich habe nämlich ein Problem mit genügend Beispielen. Ich weiß zwar wie das mit DB theoretisch geht, aber so richtig Praxiserfahrung konnte ich leider noch nicht sammeln.
beispiele entstehen immer bei n:m beziehungen zweier entitäten. dann braucht man nämlich eine weitere beziehungstabelle, um die beziehung bei rdbms abbilden zu können. ein beispiel dafür wäre die beziehung zwischen kunde und artikel, sie ist klassisch n:m. eine kunde kann mehrere artikel kaufen, ein artikel kann von mehreren kunden gekauft werden. das ist sicherlich eine vereinfachte darstellung und gibt raum für eine weiterführung. so kann eine kunde ein artikel nur einmal kaufen. was aber, wenn der gleiche kunde zu unterschiedlichen zeiten einen artikel nochmal kaufen will. dann nimmt man eben das datum mit in den pk rein, falls man davon ausgeht, nur eine bestellung des gleichen kunden pro tag. macht ja auch sinn ;-)
Ilja