SQL: Primary / Foreign Key & References

Dieses Thema im Forum "Datenbanksysteme für das Web" wurde erstellt von misterbecks, 17.07.2006.

  1. misterbecks

    misterbecks Thread Starter MacUser Mitglied

    Beiträge:
    2.159
    Zustimmungen:
    16
    MacUser seit:
    06.11.2004
    Ich arbeite mich gerade in SQL ein, allerdings fehlen mir für die o.g. Begriffe noch Verwendungsmöglichkeiten und damit das Verständnis.

    In welchen Zusammenhang wird ein PRIMARY KEY gebraucht?
    FOREIGN KEY: Nutzen?
    REFERENCES: Nutzen, wenn nicht mit ON DELETE CASCADE / SET NULL verbunden?
     
  2. master_p

    master_p MacUser Mitglied

    Beiträge:
    1.065
    Zustimmungen:
    23
    MacUser seit:
    31.01.2005
    Primary Key (Primärschlüssel) ist ein einmaliger Eintrag eines Datensatzes, damit man ihn zweifelsfrei erkennen (und ansprechen) kann. Zum Beispiel eine automatisch hochzählende ID.

    Ein Foreign Key (Fremdschlüssel) ist ein Feld in der Tabelle, der auf einen anderen Primary Key verweist.

    Beispiel:

    Tabelle: Kunde
    Felder:
    kunde_id <-- Primary Key
    kunde_name
    ...

    Tabelle: Rechnungsadresse
    Felder:
    rechnungsadress_id <-- Primary Key
    rechnungsadress_kunde_id <-- hier Foreign Key
    ...

    Ansonsten findest Du hier noch weiterführende Informationen.
     
  3. misterbecks

    misterbecks Thread Starter MacUser Mitglied

    Beiträge:
    2.159
    Zustimmungen:
    16
    MacUser seit:
    06.11.2004
    Ok, das war klar. Aber wie sieht es mit der Verwendung aus?
    Code:
    UPDATE kunde
    SET kunde_name = 'Hans'
    WHERE kunde_id = 10;
    Auf kunde_id kann ich doch auch so zugreifen, wo liegt der Vorteil bei einem Primärschlüssel?
     
  4. worf

    worf MacUser Mitglied

    Beiträge:
    848
    Zustimmungen:
    13
    MacUser seit:
    06.01.2005
    Die Summe aus Primary Keys und Referenzen
    wird unter anderem dazu genutzt vom Datenbank System
    die Logische Konsistenz der Daten zu erzwingen.

    Stell dir bei dem obigen Beispiel vor das es den PrimaryKey KUNDEN_ID nicht geben würde.

    Dann wäre es möglich das z.B. durch einen Programmfehler 2 Kunden mit der ID 10 angelegt werden. Welcher ist dan bei der Dereferenzierung nun der richtige ? Müller oder Meier ;-)

    LG Worf
     
  5. misterbecks

    misterbecks Thread Starter MacUser Mitglied

    Beiträge:
    2.159
    Zustimmungen:
    16
    MacUser seit:
    06.11.2004
    Das ist logisch und erklärt es. Würde aber dann nicht einfaches UNIQUE reichen?

    Aber die Bedeutung der Referenz ohne die o.g. Bedingungen ist noch nicht ganz klar.....
     
  6. andi.reidies

    andi.reidies MacUser Mitglied

    Beiträge:
    420
    Zustimmungen:
    0
    MacUser seit:
    08.02.2005
    Die Primärschlüssel dienen wirklich zunächst dazu, den Datenbank-Satz eindeutig zu gestalten. Einige Datenbanksysteme -e.g. SQL Server- nutzen diese Information jedoch auch, um die Daten in einer gewissen Reihenfolge im Datenbankspeicher abzulegen.

    Kurzum: jede Tabelle sollte um einen Primärschlüssel verfügen.

    Die Fremdschlüssel sind nun dazu da, dass in der o.g. Bestellungstabelle keine Kunden-ID eingetragen wird, die in der Kunden-Tabelle nicht existiert. Hier geht es also primär um die Sicherstellung der Konsistenz der Daten. Ein Versuch eine nicht vorhandene Kunden-ID einzustellen, lehnt das Datenbanksystem mit einer Fehlermeldung ab.

    Über die References-Schlüsselwörter kann dann noch spezifiziert werden, was das Datenbank-System machen soll, wenn der Master-Satz gelöscht wird. Im obigen Fall: was passiert mit den Sätzen in der Bestellung-Tabelle, wenn der Kunde gelöscht wird ? Sollen a) alle Bestellungs-Sätze zu diesem Kunden auch gelöscht werden (CASCADE DELETE) oder b) sollen die Bestellungs-Sätze im Kunden-ID Feld mit NULL gefüllt werden etc. pp. Ausserdem kann angegeben werden, dass eine Änderung der Kunden-ID (Primärschlüssel auf der Kundentabelle) automatisch auch alle referenzierten Sätze in der Bestellungstabelle mit aktualisiert (CASCADE UPDATE)....

    gruss
    andi
     
  7. Jakob

    Jakob MacUser Mitglied

    Beiträge:
    1.067
    Zustimmungen:
    21
    MacUser seit:
    05.01.2004
    Klar, dann kannst Du aber auch nur einen „Müller“ anlegen.
     
  8. worf

    worf MacUser Mitglied

    Beiträge:
    848
    Zustimmungen:
    13
    MacUser seit:
    06.01.2005

    Das ist so nicht richtig :p

    Schliesslich wird die ID als Primary Key Hinterlegt nicht der Name.

    Unter Umständen verhindert der Primary Key zusätzlich zur
    Eindeutigkeit der Werte auch noch das Anlegen eines Datensatzes mit Null
    Wert in der PK Spalte. Also ein Kunde ganz Ohne ID.

    Auch das könnte recht hilfreich sein.
    ORACLE z.B. macht das meines Wissens Nach so.
    Dort wird das z.B. erzwungen weil ORACLE Sätze mit Null in einer Schlüsselspalte nicht im Index führt.

    Würde der Primary Key nun z.B. Null Werte zulassen dann müsste der Server unter Umständen die gesammte Tabelle lesen um zu prüfen ob nicht doch noch irgendwo ein Datensatz rummliegt der zufällig in der PK Spalte keine Daten (eben Null) enthält.

    Warum kannst du die Primary Key Definition nicht einfach hinnehmen so wie Sie ist?

    Die ganzen gelerten rund um Cod werden schon gewusst haben was sie da machen.

    Und der Ansatz das man jeder Tabelle zumindest einen Primary Key gönnen sollte bringt oftmals viele Vorteile.

    LG Worf
     
  9. Jakob

    Jakob MacUser Mitglied

    Beiträge:
    1.067
    Zustimmungen:
    21
    MacUser seit:
    05.01.2004
    Hatte mich verlesen. Ich dachte er möchte statt einer Primary Key-Spalte einfach ein UNIQUE auf die Namen legen und dadurch Eindeutigkeit wahren.

    Da dem nicht so ist… über was reden wir hier jetzt überhaupt?

    Primary und foreign keys können Beziehungen zwischen Tabellen herstellen und so Konsistenz wahren. Wenn Du nur eine Tabelle hast, würde afaik theoretisch ein UNIQUE und ein INDEX auf die pseudo-primary key-Spalte reichen.

    Aber das ist eher Haarspalterei.
     
  10. misterbecks

    misterbecks Thread Starter MacUser Mitglied

    Beiträge:
    2.159
    Zustimmungen:
    16
    MacUser seit:
    06.11.2004
    Ähm, jetzt kommt glaube ich so einiges durcheinander....

    Das kann ich ohne Probleme (habe auch nie das Gegenteil behauptet), ich würde es nur gerne komplett verstehen.
    Und genau um diese Vorteile geht es hier!

    Du hast dich nicht verlesen, bzw. nur teilweise. Ich möchte UNIQUE auf die Kundennummer legen, um das
    zu verhindern. Gleicher Effekt, oder?

    Nicht ganz. Es geht um den Sinn und Nutzen einer Funktion.

    Ok, gut erklärt.
     
Die Seite wird geladen...

Diese Seite empfehlen