Zweispaltige Keys - wie handhabt ihr die Erzeugung von neuen Keys?

hustbaer

Beispiel:

AUTHOR:
Author_ID int PRIMARY KEY

WERK:
Author_ID int PRIMARY KEY
Werk_Nummer int PRIMARY KEY

Mal ganz davon abgesehen dass es in diesem Fall vermutlich günstiger wäre direkt eine für sich eindeutige "Werk_ID" zu verwenden...

Frage: wie handhabt ihr die Erzeugung von neuen Werten für "Werk_Nummer"?

Die Werk_Nummer soll dabei natürlich für jeden Author bei 1 anfangen, und schön nach Adam Riese raufzählen (1, 2, 3, 4 ...).

Macht ihr da eine eigene Tabelle für sowas?
Oder eine Splate in der AUTHOR Tabelle?
Oder etwa gar über SELECT MAX(Werk_Nummer) + 1 WHERE Author_ID = X?
Oder ganz anders?

In meinem jugendlichen Leichtsinn würde ich komplett auf mehrspaltige Indices verzichten (hat mir immer nur Ärger bereitet, diese zu verwenden).

Ich würde die AUTHOR_ID komplett aus der Tabelle WERK raushalten und statt dessen eine Tabelle verwenden, die die zueinander gehörenden IDs enthält.

So kann man die Werke und die Autoren jeweils als komplett eigenständige Entitäten betrachten und auch mehrere Autoren bei einem Werk realisieren.

Eine Werknummer als solches würde ich gar nicht mitführen, die ergibt sich doch aus dem Erscheinugnsdatum, das wäre mir wichtiger, als eine bloße Nummer.

Cpp_Junky

Mehrspaltige Indizes eignen sich gut für Integritätsprüfungen (z.B. Unique Keys über mehrere Felder). Als Primary Key kann man eigentlich auch immer ein zusätzliches ID Feld einfügen und den PK dort drauflegen, anstatt sich mit den Tücken mehrerer Felder rumzuschlagen. Und bei normalen Indizes zum Beschleunigen sollte man erstmal nachforschen ob und in welchen Situationen das genutzte DBMS bei mehreren Key-Feldern überhaupt optimiert.

witte

Ich würde es auch noch davon abhängig machen wieweit der ORM mitspielt.

hustbaer

@Joe_M:
Das Beispiel war schlecht. In meinem Fall kann es keinen N:N Beziehungen geben.

@Cpp_Junky:
Genau aus dem Grund, nämlich um die Integrität über FK-Constraints erzwingen zu können, will ich einen zweispaltigen Key verwenden.
(Ob das "Target" des FK dann auch der PK der jeweiligen Tabelle ist, ist ja auch egal. Ich halte es so dass wenn möglich ein FK immer nur auf einen PK verweist, aber darum geht's mir auch nicht bei dieser Frage.)

@witte:
Es gibt keinen ORM.

----

Worum es konkret geht ist auch ganz egal, da es denke ich öfters mal Fälle gibt, wo man mehrspaltige Keys verwenden kann/will/wird.
Ich will auch nicht wissen ob ihr das für schlau haltet.

Nur wie ihr die Keys generiert.

witte

Mir scheinen das eher zwei verschiedene Fragestellungen zu sein:
* wie erstellt man eine lückenlose Sequenz?
* sollte die Nummer Bestandteil des Primärschlüssels sein?

Wenn ein Schlüsselteil kein Surrogat sein soll würde ich die Generation von der jeweiligen Situation abhängig machen. Sollen z.B. verlorene Positionen/Lücken wieder aufgefüllt werden?
Eine Extra-Tabelle für die Positionen (Werknummer) ist m.E. falsch modelliert, da sie in 1:1 Beziehung zum Autor steht und deshalb eher dort abgelegt werden soll. Aber in beiden Fällen entsteht Redundanz.
Das SELECT MAX() + 1 ist eigentlich gar nicht so schlecht wenn ein Schlüssel Eindeutigkeit erzwingt und somit Benutzersynchronisation erzwingt. Eine andere Möglichkeit wäre die Generation auf dem Client, beispielsweise bei Patientennummern.

hustbaer

Also es sind keine Surrogate-Keys. Die Anforderung dass die "Werks-Nummern" für jeden "Autor" bei 1 anfangen impliziert das ja bereits (bei einem Surrogate-Key wäre es vollkommen egal wo der anfängt und wie er "zählt").

Hmpf.

Lücken sollen nicht aufgefüllt werden.
Und Nummern dürfen auch nicht neu vergeben werden. Selbst wenn es keine FKs mehr gibt die auf eine Nummer referenzieren, da es ausserhalb der Datenbank noch "verweise" auf die Nummer geben könnte.

Ich gehe auch davon aus, dass die "Werke" nie gelöscht werden dürfen. Demzufolge wäre ein Neu-Vergeben auch garnicht möglich.

Trotzdem habe ich bei "MAX() + 1" immer ein etwas ungutes Gefühl.

Was die Frage "sollte die Nummer Bestandteil des Primärschlüssels sein?" angeht: mir erstmal vollkommen egal, da die "Werksnummer" (mit den beschriebenen Eigenschaften) trotzdem benötigt wird. Irgendwie müssen die "Werksnummern" also auf jeden Fall generiert werden, ganz egal ob man zusätzlich dann noch einen Surrogate-Key verwendet.