Datenbank Primary Key

[idefix2]

Der Primary key ist aber nichts anderes als ein willkürlich ausgewählter eindeutiger Schlüssel. Wenn Du die Datensätze über unterschiedliche Schlüssel eindeutig identifizieren kannst, dann kannst Du theoretisch jede beliebige Kombination von Feldern, die die Datensätze eindeutig identifizieren, zum primary key ernennen. Früher hab ich das gelegentlioch so gehandhabt, es ist mir aber noch jedesmal später auf den Kopf gefallen. Deshalb die Empfehlung, als Primary Key prinzipiell ein künstliches Feld zu verwenden, das mit Hilfe eines insert-Triggers und eines Generators (neuerdings heisst das auch in Firebird - SQL Standard gemäss - Sequence) gesetzt wird.

[DeddyH]

Das hat ja auch niemand bestritten. Ich persönlich verzichte allerdings gelegentlich auf einen Generator, wenn es sich um eine Auflösungstabelle einer m:n-Beziehung handelt. In dem Fall kann man IMO auch getrost die Kombination der beiden FKs als PK definieren. Wobei es natürlich auch nicht schadet, auch hier einen künstlichen Schlüsel zu erzeugen und die angesprochene Kombination einfach UNIQUE zu deklarieren. Wie man sieht gibt es hier mehrere Möglichkeiten.

[idefix2]

Ja, Du hast schon Recht. Wenn es sich nur um eine Auflösungstabelle einer m:n-Beziehung handelt, könnte man sich das künstliche Feld samt Trigger wahrscheinlich sparen.

[mkinzler]

Er schadet aber nicht und ermöglicht eine spätere Erweiterung

[JoltinJoe]

Hm okay eine Sache ist noch unklar.

Wenn ich ein Feld_A habe und dieses als PK definieren will dann soll ich ein künstliches K_Feld_A erzeugen und einen Trigger auf das eigentliche Feld_A setzen. Danach kann ich K_Feld_A als PK definieren.

Und was soll das ganze ? Warum definiert man nicht gleich das Feld_A als PK ?

[fkerber]

Hi!

Du sollst keinen Trigger auf Feld_A setzen. Ein Trigger ist einfach eine Funktion, die z.B. bei jedem Insert aufgerufen wird (in dem Fall hier vor dem Insert - ein sog. before-Trigger)

Machen wir mal ein prakt. Beispiel:
Du hast eine Tabelle "Adressdaten" mit den Feldern "Strasse, Hausnummer, PLZ, Ort, Land" - nach den Anforderungen deines Systems sind alle diese Felder nötig, um eine Adresse eindeutig zu identifizieren. Du müsstest also einen PK definieren, der über alle 5 Felder geht.
(Würdest du z.B. nur Strasse+Hausnummer nehmen würden diese 2 Einträge nicht gehen:
"Hauptstr., 22, 12345, Testort, Testland" und "Haupstr., 22, 98765, Musterstadt, Musterland".

Somit hast du jetzt einen ziemlich unhandlichen PK in der Hand.
Sagen wir mal, du hast eine Tabelle Person [Vorname, Nachname] (auch beide zusammen als PK) und willst der Person eine Adresse zuordnen - das Ganze als n:m-Beziehung (also mehrere Personen an einer Adresse, mehrere Adressen pro Person), dann musst du in der Tabelle, die diese Beziehung ausdrückt, die Schlüssel der beiden beteiligten Tabellen haben. D.h. du hast hier eine Mega-Tabelle mit 7 Attributen.

So, würdest du sowohl bei Person wie auch bei Adresse einen künstlichen PK erzeugt hast (fortlaufende Nummerierung), dann identifiziert das eindeutig. D.h. du brauchst in der Beziehunstabelle nur 2 Felder, die ID von Person und die ID von Adresse.

Ich hoffe, ich konnte etwas Licht ins Dunkle bringen.


Liebe Grüße,
Frederic

[JoltinJoe]

Jo alles klar das hab ich kapiert

Nochmal zu der Frage "Warum lassen sich Daten mit einem PK schneller abrufen?" : Das macht doch nur Sinn wenn in der Abfrage der abzurufende Schlüssel bekannt ist ?

[mkinzler]

Das zusätzlich Feld wird zum PK. Das hat den Vorteil, dass die Werte im FELD_A später geändert werden können ohne dass Fremdschlüsselbeziehung zerstört werden bzw. angepasst ´werden müssten.

[idefix2]

Es geht da nicht um "schneller".
Der PK muß Unique sein. Auch wenn im Moment iregend eine Feldkombination unique ist, muß das nicht immer so bleiben. Beispiel:

Du hast einen Unique Key: Name, Vorname, Wohnort.
Dein Programm funktioniert wunderbar, und greifst überall in Deinem Programm mit diesem primary Key auf die Tabelle zu. Jetzt kommst Du irgendwann drauf, dass es in Berlin zwei verschiedene Hans Meier gibt, die Du in Deiner Datenbank verwalten musst, und brauchst deshalb für die Eindeutigkeit noch zusätzlich das Feld Strasse. Dann musst Du überall in Deinem Programm in allen Abfragen den Zugriff auf die Datenbank anpassen, alle Fremdschlüssel, die in anderen Tabellen auf diese Tabelle verweisen, müssen geändert werden usw.
Wenn Du aber von vorneherein ein künstliches Feld als PK verwendest, bedeutet so eine Änderung nur minimalen Aufwand.