Warum Primary Key und/oder Foreign Key ?

[fkerber]

Hi,

Zitat von RWarnecke:

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 ?

Weder noch


Liebe Grüße,
Frederic

[mkinzler]

Zitat:

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

Den gleichen Namen nicht, aber sie müssen PK sein

[RWarnecke]

Hallo Markus, Hallo Frederic,

danke für euren Hinweis. Habe auch jetzt das Beispiel von Markus hinbekommen.

Zitat von RWarnecke:

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.

Was ist hiermit, gibt es noch weitere Vorteile und gibt es noch Stolpersteine die man beachten muss ?

[mkinzler]

Zitat:

* Update der verknüpften Felder über mehrere Tabellen hinweg.

Jein, bnötigt etwas Mehrarbeit und würde auch ohne Fremdschlüssel gehen, dann aber u.U. mit deutlich mehr Aufwand

Zitat:

* Löschen von allen Datensätzen über mehrere Tabellen, die über die Felder verknüfpft sind.

Oder Verhinderung der Löschung von datensätzen in Mastertabellen, wenn noch Detaildatensätze bestehen

Zitat:

* Einträge in der Detail-Tabelle können erst gemacht werden, wenn der verknüpfte Datensatz in der Master-Tabelle eingetragen ist.

Ja

Zitat:

Gibt es noch weitere Vorteile und gibt es irgendwelche Stolpersteine, die man beachten sollte ?

Bezieht sich deine Frage auf das Konstrukt oder das Prinzip?

Zitat:

Wie zum Beispiel das die Änderungsregel und die Löschregel jeweils durchgehend gleich ist.

Derartige Regeln sollte man sich gut überlegen und ggf durch Rechteverwaltung schützen, denn eine kaskadierender delete eines falschen Datensatzes könnte bei entsprechenden Struktur zum Leeren der gesamten Datenbank führen

[RWarnecke]

Zitat von mkinzler:

Zitat:

* Update der verknüpften Felder über mehrere Tabellen hinweg.

Jein, bnötigt etwas Mehrarbeit und würde auch ohne Fremdschlüssel gehen, dann aber u.U. mit deutlich mehr Aufwand

Dann habe ich glaube ich Dein Beispiel falsch umgesetzt. Denn ich habe in der Tabelle Rechnung nur die Spalte ID und in der Tabelle Rechnungsposition die Spalte Rechnung als PK gesetzt. Zusätzlich habe ich dann noch den FK in der Tabelle Rechnungsposition gesetzt und damit die beiden PK's verbunden. Ich nehme mal an, das war nicht ganz das was Du mit dem Beispiel erreichen wolltest oder ? Siehe Beispiel von David.

Zitat von mkinzler:

Zitat:

Gibt es noch weitere Vorteile und gibt es irgendwelche Stolpersteine, die man beachten sollte ?

Bezieht sich deine Frage auf das Konstrukt oder das Prinzip?

Auf beides. Wo gibt es welche und worauf sollte man achten ?

Zitat von mkinzler:

Zitat:

Wie zum Beispiel das die Änderungsregel und die Löschregel jeweils durchgehend gleich ist.

Derartige Regeln sollte man sich gut überlegen und ggf durch Rechteverwaltung schützen, denn eine kaskadierender delete eines falschen Datensatzes könnte bei entsprechenden Struktur zum Leeren der gesamten Datenbank führen

Wie sieht das hier aus mit SET DEAFULT und SET NULL ?

Ein weiterer Vorteil ist, dass ich immer eine sortierte Tabelle nach dem PK habe.

[fkerber]

Hi!

Zitat von mkinzler:

Zitat:

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

Den gleichen Namen nicht, aber sie müssen PK sein

Bist du dir da sicher?
Afaik muss es nur ein Kandidatenschlüssel sein (klar), aber eben nicht der PK. Wiki (englisch zumindest) gibt mir da auch recht...


Grüße, Frederic

[RWarnecke]

Stimme hier Frederic mit meinem doch begrenzten Wissen zu dem Thema zu. Habe eben ein Feld als Uniques deklariert und konnte dieses in den FK einfügen und verbinden, zumindest unter Firebird.

[mkinzler]

Zitat:

Dann habe ich glaube ich Dein Beispiel falsch umgesetzt. Denn ich habe in der Tabelle Rechnung nur die Spalte ID und in der Tabelle Rechnungsposition die Spalte Rechnung als PK gesetzt.

Ja den in beiden Tabellen wäre es die Spalte ID. Die Spalte Rechnung der Positionstabelle ist der Fremdschlüssel der den Primärschlüssel der Mastertabelle (Rechnung) referenziert.

Zitat:

Zusätzlich habe ich dann noch den FK in der Tabelle Rechnungsposition gesetzt und damit die beiden PK's verbunden. Ich nehme mal an, das war nicht ganz das was Du mit dem Beispiel erreichen wolltest oder ?

Nein, hatte aber genau geschrieben, was PK und was FK ist.

Zu solltest dir vielleicht im Allgemeinen mal die Grundlagen von relationalen Datenbanksystemen anschauen.

[RWarnecke]

Zitat von mkinzler:

Zitat:

Dann habe ich glaube ich Dein Beispiel falsch umgesetzt. Denn ich habe in der Tabelle Rechnung nur die Spalte ID und in der Tabelle Rechnungsposition die Spalte Rechnung als PK gesetzt.

Ja den in beiden Tabellen wäre es die Spalte ID. Die Spalte Rechnung der Positionstabelle ist der Fremdschlüssel der den Primärschlüssel der Mastertabelle (Rechnung) referenziert.

Zitat:

Zusätzlich habe ich dann noch den FK in der Tabelle Rechnungsposition gesetzt und damit die beiden PK's verbunden. Ich nehme mal an, das war nicht ganz das was Du mit dem Beispiel erreichen wolltest oder ?

Nein, hatte aber genau geschrieben, was PK und was FK ist.

In dem Beitrag mit Deinem Beispiel steht leider nichts vom FK drin. Werde es aber nochmals mit der jetzigen Bemerkungen versuchen umzusetzen.

Zitat von mkinzler:

Zu solltest dir vielleicht im Allgemeinen mal die Grundlagen von relationalen Datenbanksystemen anschauen.

Hättest Du dazu ein paar gute Links ?

[mkinzler]

Zitat:

In dem Beitrag mit Deinem Beispiel steht leider nichts vom FK drin.

Doch

Zitat:

Die ID Felder sind PK
Kunde, Rechnung Artikel sind PKs ( hiewrbei betrachte ich aber nur die Master/Detail Beziehung zwischen REechnungsposition und Rechnung.

Zitat:

Hättest Du dazu ein paar gute Links ?

http://de.wikipedia.org/wiki/Relationale_Datenbank
http://v.hdm-stuttgart.de/~riekert/lehre/db-kelz/
http://www.ib.hu-berlin.de/~is/rel-db2.htm