SQL Primary Key Frage

[Magic1416]

Hi,

ich habe kürzlich in einer MSSQL Datenbank gesehen, dass der Primary Key über mehrere Felder hinweg definiert wurde. Meiner Meinung nach würde die DB auch mit einem Feld als Primary Key funktionieren. Daher die Frage: Welchen Sinn macht es, einen Key über mehrere Felder zu definieren ? Was gibt es für sinnvolle Anwendungsgebiete ? Wie sieht eigentlich der passende Foreign Key dazu aus ?

Danke

Gruss Magic

 

[Creeed]

Ein zusammengesetzter PK macht in Zwischentabellen Sinn. Wenn man zum Beispiel einer Rechnung Positionen mit Artikeln zuordnet. Also PK aus Rechnungsnummer und Artikelnummer, da sich ein Artikel seltenst auf einer Rechnung mehrfach als Einzelposition findet.

Der FK verweist normalerweise immer auf Attribute, also sieht er nicht anders aus als normal. In dem Beispiel mit der Rechnung wäre ein FK auf den PK der Tabelle mit den Rechnungen und ein anderer auf den PK der Artikeltabelle.

 

[ribooo]

Ein primary key ist immer unique, und bei oracle im index (ka wie es bei anderen Datenbanken aussieht).

Wenn du keinen Wert hast der gerade durch eine sequenz definiert wird und dein primär schlüssel wird, ist es sinnvoll sich die attribute zu nehmen die unique sind.

Stell dir z.b. eine Tabelle vor welche Kreditkarten beinhaltet:


credit_card_id => z.b. irgend ne referenz auf ne KK
group_id => z.b. irgend ne Referenz auf ein Gruppentyp (blacklist KK, fremde KK, usw usf)
dann irgendwelche anderen Felder die uns hier nicht interessieren


Wenn jetzt nur die "credit_card_id" der Primärschlüssen wäre könnte jede kreditkarte nur in einer Gruppe sein. Nimmst du jetzt dagegen die group_id mit in den primärschlüssel rein, könnte jede Kreditkarte in X diversen Gruppen sein.

Und zum foreign key, ist 1A das selbe wie eine refenrenz mit nur einem Feld, nur dass du einfach 2 Felderreferenzierst ==> REFERENCES tabelle(field1,field2);

Hoffe dass es dir ein wenig hilft

 

[Magic1416]

Hmm, also so wie ich es jetzt Anhand Eurer Beschreibung verstanden habe würde ich es jetzt folgendermaßen anlegen:
Tabelle 1:
ID --> bigint, Auto Increment, unique, not null
Name1 --> nvarchar, PK, unique, not null
Name2 --> nvarchar, PK, unique, not null
sonstiges --> nvarchar

Tabelle 2:
_Name1 --> nvarchar, FK, unique, not null
sonstiges --> nvarchar

Tabelle 3:
_Name2 --> nvarchar, FK, unique, not null
sonstiges --> nvarchar

Aber es müsste doch dann auch so gehen indem man einfach ne ID hernimmt:

Tabelle 1:
ID --> bigint, PK, Auto Increment, unique, not null
Name1 --> nvarchar, unique, not null
Name2 --> nvarchar, unique, not null
sonstiges --> nvarchar

Tabelle 2:
_ID --> bigint, FK, unique, not null
sonstiges --> nvarchar

Tabelle 3:
_ID --> bigint, FK, unique, not null
sonstiges --> nvarchar

Mit der passenden inner join Abfrage komme ich doch zum selben Ergebnis. Verstehe ich die Zusammenhänge da richtig ?

Gruss Magic

 

[BerniG]

Bei dir sieht es ja so aus, dass du eine künstliche ID per AutoIncrement vergibst. Da diese ID immer eindeutig ist, ist der PK eigtl. nur das Feld ID.
Indexe über mehrere Spalten machen Sinn, weil man bei komplexeren Tabellen damit die Performance verbessern kann, insbesondere wenn man über mehrere Spalten joined. Außerdem kann man eben Uniquewerte über mehrere Spalten definieren, so wie RIBoSoME das ja schon erklärt hat. Ob man dies nun über einen PK oder einen zusätzlichen Index macht ist prinzipiell nicht so wichtig bzw. hängt eben vom Datenmodell ab. In manchen Datenbanken hat der PK zwar eine minimal spezielle Bedeutung aber grundsätzlich ist es auch nur ein Unique Index.

 

[Magic1416]

@all

ich glaub ich habe die Thematik verstanden. Danke für Eure Infos.

Gruss Magic