Was sollte der Primärschlüssel sein?

Ich bin auf ein Problem gestoßen, das ich nicht lösen kann.

Sag zum Beispiel, dass ich einen Tisch mit kommenden Videospiel-Veröffentlichungen habe:

GAME game_ID | title ----------------------------- 1 | Super Mario 2 | Final Fantasy XIII 

Und dann habe ich eine Tabelle mit Releases (verschiedene data für ps3 und xbox360 nur für das Argument):

 RELEASES game_ID | releasedate | platform --------------------------------- 1 | 20-04-2010 | Wii 2 | 23-03-2010 | PS3 3 | 20-03-2010 | Xbox360 

Jetzt habe ich game_ID als Primärschlüssel in die Tabelle "GAME" gesetzt. Und game_ID ist auch ein Fremdschlüssel in der Tabelle "RELEASES". Was sollte ich als Primärschlüssel in letzterem haben? Es erscheint eher unnötig, einen weiteren ID-Schlüssel in der "RELEASES" -Tabelle anzulegen?

Kann ich irgendwie game_ID und Plattform zusammen verwenden, um den Primärschlüssel zu erstellen? Wenn ja, wie würde SQL aussehen?

Solutions Collecting From Web of "Was sollte der Primärschlüssel sein?"

Sie können einen zusammengesetzten Schlüssel erstellen, der aus game_id und platform genauso wie Sie einen Primärschlüssel erstellen, der nur aus einer Spalte besteht:

 PRIMARY KEY(game_id, platform) 

Sie möchten nicht, dass game_ID der Primär- und der Fremdschlüssel in der Releasetabelle ist. Das würde verhindern, dass die Tabelle für jedes Spiel mehr als einen datasatz enthält, da der Primärschlüssel eindeutig sein muss. Ich würde eine Struktur wie diese empfehlen.

 RELEASES release_ID | game_ID | releasedate | platform --------------------------------------------- 1 | 1 | 20-04-2010 | Wii 2 | 1 | 23-03-2010 | PS3 3 | 1 | 20-03-2010 | Xbox360 

release_ID würde automatisch generiert werden. Sie können einen zusammengesetzten Schlüssel verwenden, indem Sie die Plattform in den Primärschlüssel einbeziehen, aber es kann zu einem Problem kommen, wenn ein einzelnes Spiel / eine Plattform mehrere Versionen hat. Du denkst vielleicht nicht, dass das jetzt möglich ist, aber die Dinge ändern sich.

Ich halte es auch für eine gute Praxis, niemals eine Spalte zu verwenden, die als Schlüssel eine Bedeutung hat, da sich die Dinge ändern und man nicht vorhersagen kann, wie sie sich verändern werden. Wenn Schlüssel für Endbenutzer bedeutungslos sind, können sie sich nicht mit der Struktur Ihrer database anlegen.

Betrachten Sie zunächst die Realisierung von Plattformen als separate Nachschlagetabelle. Dies verringert nicht nur die Gefahr von databeschädigungen, sondern erleichtert auch die Definition Ihrer Schlüssel.

Ein Primärschlüssel muss nicht auf ein Feld beschränkt sein. Sie können einen zusammengesetzten Primärschlüssel mit mehreren Feldern definieren.

In diesem Fall würde ich jedoch davon abraten, den zusammengesetzten Primärschlüssel zu verwenden, und würde die Erstellung eines neuen Primärschlüssels in der Versionstabelle befürworten.

Warum? Nun, für den Anfang, ich glaube nicht, dass Sie genug Informationen in Releases erfasst haben. Zum Beispiel werden Videospiele oft zu unterschiedlichen timeen in verschiedenen Regionen veröffentlicht, so dass es durchaus möglich wäre, zwei Versionen für dasselbe Spiel und dieselbe Plattform zu haben. In diesem Fall benötigen Sie einen zusammengesetzten Primärschlüssel mit drei Feldern. Wo endet es? 🙂

Indem Sie ReleaseID als Ersatzprimärschlüssel definieren, geben Sie sich in Zukunft viel mehr Spielraum für Veränderungen.