Wie geht man mit zusammengesetzten Primärschlüsseln um?

[p80286]

Warum machst Du solche Klimmzüge?

Code:

Artikel:
Artikel_ID [PK]
Artikel

Beschreibung:
Beschreibung_ID [PK]
Artikel_ID  [FK]
Sprache

sollte voll und ganz ausreichen.
(daß die PKs aus dem Generator kommen setz ich mal als selbstverständlich voraus)

Code:

select sprache from Beschreibung where Artikel_ID=:Artikel_id;

Gruß
K-H

[Hansa]

Zitat von p80286:

..daß die PKs aus dem Generator kommen setz ich mal als selbstverständlich voraus..

Au mann. Ich setze jedenfalls mal voraus, dass die Generatoren dazu benutzt werden, wozu sie gedacht sind : als transaktions-unabhängige also quasi auch Datenbank-unabhängige Zähler. Am Besten interpretiert man da nicht noch eine Pseudo-Logik hinein.

Zusammengesetzte Primary Keys sind wohl auch nicht besinderss gute Idee. Wozu gibts denn Unique Keys ?

[Jumpy]

Hallo,

ich hab auch schon mit einer DB gearbeitet (nicht von mir) da hatte jede Tabelle einen PK aus zwei Feldern. Jedes enthielt die Hälfte einer GUID/UUID. Das war irgendwie historisch so gewachsen, weil das aus einer DB kam, oder mir einer DB zusammenarbeiten musste (weiß nicht mehr genau), das die komplette GUID nicht in einem Feld speichern konnte.

Es sollte aber mit der GUID als PK gearbeitet werden. Interresanterweise waren die GUID aus dem Bereich, der für per Zufall generierte GUID reserviert ist. Dementsprechend gab es auch keine Fortlaufenden Nummern, sondern es wurde für jeden neuen Datensatz eine GUID zufällig neu erzeugt. Fand ich ein spannendes Konzept und hab immer gedacht, was passiert, wenn mal zufällig eine bereits vorhandene GUID generiert wird. Ist aber afaik nie passiert.

Wollte damit auch nur sagen, dass es schon mal passieren kann, das man zwei PKs hat, obwohl es eienr auch getan hätte.