Soll ich einen zusammengesetzten Schlüssel für eine Zuordnungstabelle verwenden, die auch für einen Fremdschlüssel verwendet wird?

Question

Ich bin mit ASP.NET und dem Entity Framework, um eine Website zu machen. Im Moment habe ich eine Karte Tabelle für eine viele zu viele Beziehung zwischen ... sagen wir mal Benutzer und Fußball-Teams. Also:

Benutzer
Teams
UserTeams

Teil 1 : Ist es am beste Praxis einen zusammengesetzten Schlüssel für den Primärschlüssel der Kartentabelle zu benutzen? Mit anderen Worten:

UserTeams Tabelle
PK UserId
PK TeamId
PreferenceId

Teil 2 : Der Nachteil ist, dass ich auch einen anderen Tisch. Nennen wir es „UserTeamPredictions“, die für jedes Jahr des Benutzers Prognosen für ein bestimmtes Team speichert. Diese Tabelle hat einen Fremdschlüssel, die auf den Kartentisch zurückverweist. So sieht es etwa so aus:

UserTeamPredictions Tabelle
PK UserTeamPredictionId
FK UserId
FK TeamId
Prognose PredictionYear

Dies scheint in der Entity Framework zu funktionieren, aber ich habe einige Probleme gehabt, wenn Beziehungen in Steuerelemente von Drittanbietern verweisen, die ich wie Telerik verwenden. Auch wenn es nicht die idealen Setup-Daten sein könnte, soll ich die Tabellenstruktur / Beziehungen ändern, so dass es einfacher mit Daten in dem Code zu arbeiten, verbindlich und anderen Dinge?

Die Änderung wäre eine ganze Zahl Primärschlüssel der UserTeams Karte Tabelle hinzuzufügen, so dass der UserTeamPredictions Tabelle den Schlüssel direkt verweisen, statt durch den zusammengesetzten Schlüssel, wie es gegenwärtig der Fall ist:

UserTeams Tabelle
PK UserTeamId
FK UserId
FK TeamId
PreferenceId

UserTeamPredictions Tabelle
PK UserTeamPredictionId
FK UserTeamId
Prognose PredictionYear

Was denken Sie!?

Answer 1

Ich würde nicht wählen. Ich würde einen Ersatzschlüssel verwenden und einen eindeutigen Index für die Benutzer-ID und TeamId Spalten setzen. Ich bekomme wirklich satt zusammengesetzter Schlüssel, wenn es mehr als zwei ist, und eher als eine Mischung aus Verbund und Ersatzschlüssel habe, wähle ich mit allen Surrogat, bedeutungslos autoincrement Tasten, wo immer möglich, zu gehen.

Dies hat den Bonus, den Sie eine gute Leistung des Gebens auf beitritt, und bedeutet, dass Sie immer den Schlüssel für eine bestimmte Tabelle (Tabellenname + ID) kennen, ohne das Schema verweisen zu müssen. Einige ORM-Tools funktionieren nur richtig mit einzelnen Spalte anstatt zusammengesetzte Schlüssel, auch.

Answer 2

Sie sollten es ändern. Suche Stapelüberlauf für Diskussionen über „natürlichen Schlüssel“ - es ist fast allgemein einig, dass Ersatzschlüssel sind besser, vor allem, wenn Unternehmen Generation verwenden. Natürliche oder zusammengesetzte Schlüssel tun nicht spielt gut mit im allgemeinen Entity Framework Stil DAL Schichten. Zum Beispiel Light und Subsonic beide erfordern, dass Sie eine einzelne eindeutige Spalte als PK haben ... Lightspeed in seiner aktuellen Version geht sogar so weit, darauf zu bestehen, dass Ihre Spalte „Id“ genannt wird, obwohl die nächste Version sich ändern wird.