Zusammengesetzter Primärschlüssel oder laufende Nummer

[nathalies]

Hallo zusammen,

ich bereite mich gerade auf eine Klausur zum Thema Datenmodellierung vor und bräuchte einmal eure Hilfe.
Wir haben eine relationale Datenbank gegeben, aus der ersichtlich werden soll, welcher Spieler bei einem Spiel von welchem Beobachter welche Note bekommen hat. Ich habe den Sachverhalt aufgezeichnet.
Nun wird für die Spieler-Beobachter Tabelle eine laufende Nummer verwendet. Kann man in diesem Zusammenhang nicht auch eine Kombination aus der Spielernummer und der Beobachternummer verwenden? Gibt es dazu eine Regel, wann man eine laufende Nummer verwendet und wann einen zusammengesetzten Primärschlüssel?

Ich bedanke mich für jede Hilfe.

 

[castorp]

Nun wird für die Spieler-Beobachter Tabelle eine laufende Nummer verwendet. Kann man in diesem Zusammenhang nicht auch eine Kombination aus der Spielernummer und der Beobachternummer verwenden?

Ja, und ich würde das auch so machen.

Gibt es dazu eine Regel, wann man eine laufende Nummer verwendet und wann einen zusammengesetzten Primärschlüssel?

Es gibt viele, die stur an der Regel festhalten, dass eine Tabelle immer einen generierten Primärschlüssel haben muss. Oft ist das durch die für die Programmierung eingesetzten Frameworks bedingt (weil viele mit zusammengesetzten Schlüsseln nicht zurechtkommen).

Wenn die Tabelle von vielen anderen Tabellen referenziert wird, dann ist es häufig etwas einfacher, einen generierten Schlüssel zu nehmen, weil die Fremdschlüssel ja auch immer beide Spalten enthalten. Damit werden Joins einfacher und die referenzierenden Tabellen ein wenig kleiner - obwohl das Hinzufügen einer weiteren Integer Spalte nur einen sehr kleinen Unterschied macht (unter Umständen macht es für die physische Größe der Tabelle sogar überhaupt keine Unterschied).

In Deinem Fall sehe ich aber überhaupt keinen Vorteil des generierten Schlüssels.

 

[ukulele]

Ich kenne das (aus der Berufsschule, also absolut Basic) so das bei der Modellierung mit zusammengesetzten Schlüsseln gearbeitet wird (sind ja eindeutig und vorhanden), in der Praxis bevorzuge ich auch der Einfachheit halber den künstlichen PK. Wenn es aber auf Größe ankommt ist nicht unbedingt die Platzersparnis in der Tabelle ausschlaggebend sondern meist im Index.

Ich habe kürzlich noch einen interessanten Blog gelesen warum Integer (manchmal) ein besserer PK ist als ein UID, eben wegen der Größe im Index.

 

[castorp]

Grundsätzlich stimmt das natürlich, dass der Index größer wird, wenn man zwei Spalten speichert oder wenn man UUID statt Integer verwendet. Und das kann man auch messen.

Nach meiner Erfahrung bleibt aber in einem realistischen Last-Szenario nicht mehr sehr viel übrig von den Unterschieden. Zumal der Effekt des größeren (bzw. kleineren) Index meist nur dann wirklich messbar ist, wenn mehr geschrieben als gelesen wird. In der Realität wird aber üblicherweise deutlich mehr gelesen als geschrieben.

Klar belegt der größere Index mehr Speicher (und damit mehr Cache) aber auch das ist häufig nicht wirklich relevant.

Es gibt sicherlich Anwendungen bei denen es auf jede Millisekunden ankommt. Aber ich würde immer zuerst mit einem sauberen Design anfangen, welches auf die fachlichen Anforderungen abgestimmt ist.

 

[Walter]

Was noch nicht erwähnt wurde: eine id bewahrt einen auch vor dem Problem, wenn sich die Daten ändern. Beispiel: ein Artikel hat eine Artikelnummer, die sich nach einem Jahr ändern soll. Ist der Artikelnummer der Primary Key wird das problematisch und aufwändig. Ist eine id der Primary Key dann reicht ein simpler Update.

Das Argument, solche Daten würden sich nie ändern, kann nur jemand bringen dem das in der Praxis noch nie passiert ist.

 

[castorp]

Absolut richtig.

Aber die Frage bezog sich ja auf Primärschlüssel in Link-Tabellen die nicht notwendig sind. Wenn ich schon zwei (FK) Spalten habe die eindeutig sind, muss ich nicht noch eine dritte Spalte als PK anlegen, nur damit ich dem Mantra folge, dass jede Tabelle einen generierten PK braucht.