Delphi-PRAXiS
Seite 1 von 2  1 2      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Datenbanken (https://www.delphipraxis.net/15-datenbanken/)
-   -   Warum Primary Key und/oder Foreign Key ? (https://www.delphipraxis.net/152735-warum-primary-key-und-oder-foreign-key.html)

RWarnecke 4. Jul 2010 13:10

Datenbank: egal • Version: egal • Zugriff über: egal

Warum Primary Key und/oder Foreign Key ?
 
Hallo zusammen,

ich lese immer wieder das man die beiden Key's aus dem Titel setzen soll. Mir erschliesst sich nur noch nicht, warum ich diese Key's setzen soll. Ich habe jetzt schon mehrere Beiträge und Anleitungen gelesen. Aber so richtig verstehen tue ich es trotzdem nicht. Ich habe jetzt schon mehere kleine Projekte mit Datenbanken gemacht, zum Beispiel Code-Orakel. Hier habe ich auch keine Key's gesetzt.

Nun zu meinen Fragen :
Worin besteht nun der Vorteil einen Primary Key und oder einen Foreign Key zusetzen ?
Ab wann macht es Sinn diese Key's zu benutzen ?
Würdet Ihr egal, wie groß die Datenbank wird immer einen oder beide Key's setzen ?
Hängt auch vielleicht das Design der Tabelle davon ab, ob ich einen Key setze oder nicht ?

Edit: Wo können Stolpersteine entstehen, wenn ich keinen Key setze ?

mkinzler 4. Jul 2010 13:20

AW: Warum Primary Key und/oder Foreign Key ?
 
Zitat:

Worin besteht nun der Vorteil einen Primary Key und oder einen Foreign Key zusetzen ?
Es wird dann ein Index erzeugt.
Primärschlüssel sind Voraussetzung für Fremdschlüssel.
fremschlüssel haben den Vorteil, dass man nur vorhandene Masterwerte in einer Detailtabelle auswählen kann. es sind auch Delete-Rules möglich

RWarnecke 4. Jul 2010 14:00

AW: Warum Primary Key und/oder Foreign Key ?
 
Zitat:

Zitat von mkinzler (Beitrag 1033417)
Es wird dann ein Index erzeugt.Primärschlüssel sind Voraussetzung für Fremdschlüssel.

Das würde also heißen, dass die Suche in einer Datenbank beschleunigt.
Zitat:

Zitat von mkinzler (Beitrag 1033417)
fremschlüssel haben den Vorteil, dass man nur vorhandene Masterwerte in einer Detailtabelle auswählen kann. es sind auch Delete-Rules möglich

Da sprichste in einem Rätsel. Kannste mir das bitte an einen Beispiel erklären. Ich kann mir darunter nichts vrostellen.

mirage228 4. Jul 2010 14:03

AW: Warum Primary Key und/oder Foreign Key ?
 
Zitat:

Zitat von RWarnecke (Beitrag 1033423)
Zitat:

Zitat von mkinzler (Beitrag 1033417)
fremschlüssel haben den Vorteil, dass man nur vorhandene Masterwerte in einer Detailtabelle auswählen kann. es sind auch Delete-Rules möglich

Da sprichste in einem Rätsel. Kannste mir das bitte an einen Beispiel erklären. Ich kann mir darunter nichts vrostellen.

Stell die eine Tabelle mit Mitarbeitern vor und dazu eine Tabelle mit irgendwelchen Meta-Daten über diesen Mitarbeiter. Die beiden Tabellen sind mit einem Fremdschlüssel (Mitarbeiter ID) verknüpft. Nun kannst Du es so einrichten, dass wenn die Mitarbeiter ID aktualisiert wird in der Mitarbeiter-Tabelle sind die Mitarbeiter-ID der anderen Tabellen auch mit aktualisiert wird. Oder wenn ein Mitarbeiter aus der Mitarbeitertabelle gelöscht wird, die entsprechenden Datensätze aus der anderen Tabelle automatisch mit gelöscht werdne...

mkinzler 4. Jul 2010 14:14

AW: Warum Primary Key und/oder Foreign Key ?
 
Zitat:

Das würde also heißen, dass die Suche in einer Datenbank beschleunigt.
Wenn nach dem Primärschlüssel gesucht wird
Zitat:

Da sprichste in einem Rätsel. Kannste mir das bitte an einen Beispiel erklären. Ich kann mir darunter nichts vrostellen.
Welchen Teil meinst du ( der 2. wurde schon erklärt)
Ohne Fremdschlüsselbeziehung könnten auch in der Mastertabelle nicht vorhandene Werte verwendet werden.

RWarnecke 4. Jul 2010 15:13

AW: Warum Primary Key und/oder Foreign Key ?
 
Hallo David, Hallo Markus,

erstmal danke für eure Erklärungen.So ganz kann ich noch nicht folgen. Ich versuche es mal so zu erklären, wie ich es verstanden habe. Korrigiert mich wenn irgendwas falsch ist.

Code:
Tabelle mit Mitarbeitern:
+---------------+---------+----------+-----------+---------+
+ MitarbeiterID + Vorname + Nachname + Abteilung + Telefon +
+---------------+---------+----------+-----------+---------+
+ 1000          + Hans   + Meier   + Einkauf  + -1234   +
+---------------+---------+----------+-----------+---------+
Code:
Tabelle mit Metadaten von Mitarbeitern:
+---------------+-------+------------+-------------+
+ MitarbeiterID + Alter + Geschlecht + Geburtsort +
+---------------+-------+------------+-------------+
+ 1000          + 43    + männlich  + Musterstadt +
+---------------+-------+------------+-------------+
In beiden Tabellen ist der Primary Key auf das Feld MitarbeiterID gesetzt. Bei dieser Voraussetzung, wenn ich es richtig verstanden habe, könnte ich jetzt bei beiden Datensätzen die MitarebiterID von 1000 auf 1001 ändern, richtig ?

Wenn ja, wie müsste ich da den SQL-Befehl schreiben ? Wenn nein, was habe ich falsch gemacht ?

mkinzler 4. Jul 2010 15:22

AW: Warum Primary Key und/oder Foreign Key ?
 
Jein.
Besseres Beispiel

Rechnung:
Code:
ID   Kunde Datum
...
1087  156   02.01.2010
1088  154   02.01.2010
...
Rechungspositionen:

Code:
ID   Rechnung Artikel Anzahl EP
...
7654  1087      1567    2      1,5
7655  1087      1876    3      0,99
7656  1087      765     1      2
7657  1088      1567    1      1,5
7658  1088      2345    6      0,2
...
Die ID Felder sind PK
Kunde, Rechnung Artikel sind PKs ( hiewrbei betrachte ich aber nur die Master/Detail Beziehung zwischen REechnungsposition und Rechnung.
Alle Positionen mit dem selben Wert in Rechnung gehören zu einem Eintrag in der Rechnugstabelle
Für rechnung sind nur Werte in der Tabelle Rechnung möglch. Wenn man ein delete-On-Cascade als Löschregel deklariert, werden alle Rechnungspositionen zur einer rechnung mitgelöscht, wenn diese aus der rechnungstabelle entfernt wird
-> Löscht man den Datensatz mit der ID 1087 aus der Tabelle Rechnung werden die Datensätze mit den IDs 7654, 7655, 7656 aus der Tabelle Rechnungspositionen mitgelöscht

mirage228 4. Jul 2010 15:24

AW: Warum Primary Key und/oder Foreign Key ?
 
Roter Kasten ... -- Egal, vielleicht ists ja auch noch hilfreich :mrgreen:

Hm, dann mache ich vielleicht mal ein anderes Beispiel.

Nehmen wir einen Artikel
Code:
*ID  -- Name   -- Beschreibung
-----------------------------------
1     -- Kakao  -- Lecker, lecker
Diesem kannst du beliebig viele Kategorien zuordnen:
Code:
*#ID  -- *#Kategorie
--------------------
1     -- Zuckerhaltig
1     -- Pulver
1     -- Braun
Die Raute # heißt, dass ein FK ist - der Stern, dass es ein PK ist (die "Kategorie"-Tabelle habe ich mal der Einfachheit halber weggelassen).

Löscht Du nun den Kakao:
SQL-Code:
DELETE FROM Artikel WHERE ID = 1
sind automatisch auch alle Einträge mit ID = 1 aus der Kategorien-Zuordnung weg :)

Wenn Du schreibst
SQL-Code:
UPDATE Artikel SET ID = 666 WHERE ID = 1
dann wird auch in der Kategorie-Zuordnung dies angepasst.

Du kannst die Regeln aber auch so festlegen, dass ein Löschen bzw. Update verboten wird, wenn eine ID aus der Artikel-Tabelle irgendwo über einen Fremdschlüssel referenziert wird...

Viele Grüße

DeddyH 4. Jul 2010 15:33

AW: Warum Primary Key und/oder Foreign Key ?
 
Vielleicht hilft der Wikipedia-Artikel ja, etwas Licht ins Dunkel zu bringen.

RWarnecke 4. Jul 2010 18:51

AW: Warum Primary Key und/oder Foreign Key ?
 
Hallo Detlef,

danke für Deine Antwort. Der Artikel ist ja recht umfangreich. Nur leider verwirrt er mich, werde den Artikel aber zu einem späteren Zeitpunkt nochmals durchlesen. Vielleicht verstehe ich Ihn dann besser.

@Markus & David
Danke für eure Beispiele. Das Beispiel von David konnte ich jetzt entsprechend umsetzen in einer Firebird-Besipieldatenbank. Das Beispiel von Markus habe ich noch nicht geschafft.

Das sind die Vorteile, die ich im Moment von den Schlüsseln ersehe :
  • Update der verknüpften Felder über mehrere Tabellen hinweg.
  • Löschen von allen Datensätzen über mehrere Tabellen, die über die Felder verknüfpft sind.
  • Einträge in der Detail-Tabelle können erst gemacht werden, wenn der verknüpfte Datensatz in der Master-Tabelle eingetragen ist.

Gibt es noch weitere Vorteile und gibt es irgendwelche Stolpersteine, die man beachten sollte ? Wie zum Beispiel das die Änderungsregel und die Löschregel jeweils durchgehend gleich ist.

Edit : Das hätte ich ja beinahe vergessen, müssen eigentlich die verknüpften Felder immer den gleichen Namen haben und als PK deklariert sein ?


Alle Zeitangaben in WEZ +1. Es ist jetzt 00:02 Uhr.
Seite 1 von 2  1 2      

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz