![]() |
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 ![]() 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 ? |
AW: Warum Primary Key und/oder Foreign Key ?
Zitat:
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 |
AW: Warum Primary Key und/oder Foreign Key ?
Zitat:
Zitat:
|
AW: Warum Primary Key und/oder Foreign Key ?
Zitat:
|
AW: Warum Primary Key und/oder Foreign Key ?
Zitat:
Zitat:
Ohne Fremdschlüsselbeziehung könnten auch in der Mastertabelle nicht vorhandene Werte verwendet werden. |
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:
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 ?
Tabelle mit Metadaten von Mitarbeitern:
+---------------+-------+------------+-------------+ + MitarbeiterID + Alter + Geschlecht + Geburtsort + +---------------+-------+------------+-------------+ + 1000 + 43 + männlich + Musterstadt + +---------------+-------+------------+-------------+ Wenn ja, wie müsste ich da den SQL-Befehl schreiben ? Wenn nein, was habe ich falsch gemacht ? |
AW: Warum Primary Key und/oder Foreign Key ?
Jein.
Besseres Beispiel Rechnung:
Code:
Rechungspositionen:
ID Kunde Datum
... 1087 156 02.01.2010 1088 154 02.01.2010 ...
Code:
Die ID Felder sind PK
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 ... 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 |
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:
Diesem kannst du beliebig viele Kategorien zuordnen:
*ID -- Name -- Beschreibung
----------------------------------- 1 -- Kakao -- Lecker, lecker
Code:
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).
*#ID -- *#Kategorie
-------------------- 1 -- Zuckerhaltig 1 -- Pulver 1 -- Braun Löscht Du nun den Kakao:
SQL-Code:
sind automatisch auch alle Einträge mit ID = 1 aus der Kategorien-Zuordnung weg :)
DELETE FROM Artikel WHERE ID = 1
Wenn Du schreibst
SQL-Code:
dann wird auch in der Kategorie-Zuordnung dies angepasst.
UPDATE Artikel SET ID = 666 WHERE ID = 1
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 |
AW: Warum Primary Key und/oder Foreign Key ?
Vielleicht hilft der
![]() |
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 :
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. |
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