Ankündigung

Einklappen
Keine Ankündigung bisher.

Primary Key / Foreign Key

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Midget
    hat ein Thema erstellt Primary Key / Foreign Key.

    Primary Key / Foreign Key

    Hallo,
    ich habe eine Tabelle „customers“ und eine Tabelle „deliveryAddress“.
    In Tabelle deliveryAddress schreibe ich jeweils die Lieferadresse, jedoch nur wenn diese abweichend ist
    von der Anschrift des Kunden. In diesem Fall benutze ich die customerID als Fremdschlüssel in meiner Tabelle deliveryAddress,
    über den ich dann später per LEFT JOIN auf meine Lieferadresse zugreifen kann. Also normalerweise so :
    CREATE TABLE deliveryAddress
    (
    deliveryAddressID INT NOT NULL PRIMARY KEY,
    customerID_FK INT NOT NULL,
    deliveryAddress etc …
    FOREIGN KEY(customerID_FK) REFERENCES customers(customerID)
    );
    Jetzt stelle ich mir die Frage, da ich ja maximal eine abweichende Lieferadresse pro Kunde akzeptiere, ich nicht sofort die customerID als Primary Key verwenden kann :

    CREATE TABLE deliveryAddress
    (
    customerID_FK INT NOT NULL PRIMARY KEY,
    deliveryAddress etc …

    );
    Somit würde ich nicht nur eine Spalte (die des zusätzlichen Primary Key) sparen, sondern auch noch das zusätzliche Deklarieren eines Fremdschlüssels.
    Ausserdem würde beim JOIN dann auch noch die Suche beschleunigt, da der Primary Key doch sowieso schon indexiert ist ?

    Oder bin ich auf dem Holzweg ?

  • Dormilich
    antwortet
    Beides, das eine ist MySQL, das andere SQLServer.

    Der Ausschnitt aus der Doku, wo das steht: https://dev.mysql.com/doc/refman/8.0...eign-keys.html

    Einen Kommentar schreiben:


  • Midget
    antwortet
    Achso erc, dann habe ich dich in Beitrag #4 falsch verstanden.
    Ich wußte nicht, dass ein Primärschlüssel auch gleichzeitig ein Fremdschlüssel sein kann.
    Wieder was gelernt. Danke.

    Bei einer INNODB ist doch auch ein FK genauso wie ein PK von Natur aus indexiert oder ?
    Ja.
    https://stackoverflow.com/questions/...-automatically
    In diesem Beitrag wird das bestätigt.

    https://docs.microsoft.com/de-de/sql...l-server-ver15
    Hier wird dem jedoch widersprochen:
    Im Gegensatz zu PRIMARY KEY-Einschränkungen wird bei der Erstellung einer FOREIGN KEY-Einschränkung nicht automatisch ein entsprechender Index generiert. Das manuelle Erstellen eines Indexes für einen Fremdschlüssel empfiehlt sich jedoch aus folgenden Gründen...
    Was stimmt denn nun ?

    Einen Kommentar schreiben:


  • Perry Staltic
    antwortet
    Ich weiß ja nicht, wieviel Millionen Datensätze auf die Art gespeichert werden, aber diese Sparsamkeit halte ich für kontraproduktiv. Also falsch verstandene Sparsamkeit.
    Wie erc richtig sagt, führt das Modell vor allem funktional zur Limitierung der Lieferadresse auf max. 1!
    Sollte sich das irgendwann mal ändern müssen- was mir nicht sehr weit hergeholt scheint- ist eine relativ aufwändige Migration notwendig.

    Also warum nicht lieber einen eigenständigen PK? Es werden ziemlich sicher genug Werte da sein und es werden auch genug Bytes im Storage da sein.

    Einen Kommentar schreiben:


  • erc
    antwortet
    Zitat von Midget Beitrag anzeigen
    Also so ?
    Nein, customerID ist indem Fall auch der PK.

    Code:
    CREATE TABLE deliveryAddress
    (
    customerID INT NOT NULL PRIMARY KEY,
    ...
    FOREIGN KEY(customerID) REFERENCES customers(customerID)
    );
    Ein Kunde kann damit maximal 0 bis 1 Lieferadresse haben. Wenn customerID nicht der PK ist, hast du das selbe wie vorher in grün.


    Einen Kommentar schreiben:


  • Dormilich
    antwortet
    Was ein Foreign Key ist und was nicht zeigt einem doch üblicherweise schön übersichtlich das Frontend an.
    Oder man fragt im allergrößten Notfall die information table ab.

    Einen Kommentar schreiben:


  • hellbringer
    antwortet
    Zitat von Midget Beitrag anzeigen
    und die meisten raten dort an, einen Fremdschlüssel mit FK am Ende sofort sichtlich zu machen.
    Ich würde das bleiben lassen. Habe das noch nie bei einem Projekt gehabt und auch keinerlei Nachteile durch den "fehlenden" Suffix gehabt. Ich finde solche Präfixe und Suffixe, wenn ich sie irgendwo mal sehe, eher hinderlich beim Lesen. Und einen Mehrwert bringen sie ja auch nicht wirklich. Was ein Foreign Key ist und was nicht zeigt einem doch üblicherweise schön übersichtlich das Frontend an. Wozu dann noch irgendwas dazuhängen?

    Einen Kommentar schreiben:


  • Dormilich
    antwortet
    meine Frage lautete, ob man zwingend einen PK pro Tabelle benötigt
    Eine Tabelle SOLLTE immer eine PK haben, allein schon um (und sei es nur fürs Debugging) einen einzelnen Datensatz ansprechen zu können. Außerdem fehlt dir ohne PK/UK noch die Einschränkung, dass es nur eine Lieferadresse pro Kunde gibt.

    Denn in meiner späteren Abfrage per JOIN greife ich ja lediglich auf den FK zu der in meiner Tabelle einmalig ist
    In deiner Tabelle von #5 ist das aber nicht der Fall.

    customerID_FK ist hier nicht der PK sondern der FK.
    Ich war davon ausgegangen, dass du ercs Vorschlag umsetzen wolltest.

    Einen Kommentar schreiben:


  • Midget
    antwortet
    Hallo Dormilch,

    Du kannst nur einen PK erstellen (wie der Name schon sagt). Woraus dieser PK besteht, ist der DB ziemlich egal.
    Ich weiß, daß man pro Tabelle nur 1 PK haben darf. Ich glaube, du hast dich in meiner Frage in Beitrag #5 verlesen. Ich habe hier keinen PK sondern nur einen FK
    und meine Frage lautete, ob man zwingend einen PK pro Tabelle benötigt. (Denn in meiner späteren Abfrage per JOIN greife ich ja lediglich auf den FK zu der in meiner Tabelle einmalig ist)

    Allerdings ist customerID_FK nicht gerade ein geeigneter Name für PKs.
    ..
    customerID_FK ist hier nicht der PK sondern der FK.
    Ich lese zur Zeit ziemlich viele Tutorials um mich in die Materie einzuarbeiten (von Autos versteh ich mehr )und die meisten raten dort an, einen Fremdschlüssel mit FK am Ende sofort sichtlich zu machen.




    Einen Kommentar schreiben:


  • Dormilich
    antwortet
    Es ist hier ebenfalls doch nicht zwingend nötig, noch eine extra Spalte mit einem Primary Key zu erstellen
    Du kannst nur einen PK erstellen (wie der Name schon sagt). Woraus dieser PK besteht, ist der DB ziemlich egal.

    Allerdings ist customerID_FK nicht gerade ein geeigneter Name für PKs... (wobei ich persönlich nicht besonders viel von solchen Suffixen halte)

    Bei einer INNODB ist doch auch ein FK genauso wie ein PK von Natur aus indexiert oder ?
    Ja.

    Einen Kommentar schreiben:


  • Midget
    antwortet
    Es hält dich aber auch keiner davon ab, den PK als FK zu definieren.
    Also so ?

    CREATE TABLE deliveryAddress
    (
    customerID_FK INT NOT NULL,
    deliveryAddress etc …
    FOREIGN KEY(customerID_FK) REFERENCES customers(customerID)
    );

    In diesem Fall behalte ich dann, wenn ich dich richtig verstehe, meine Constraints, was mir schon wichtig ist.
    Es ist hier ebenfalls doch nicht zwingend nötig, noch eine extra Spalte mit einem Primary Key zu erstellen, welche ich eh nicht nutze in meiner Abfrage, oder ?
    Und letzte Frage : Bei einer INNODB ist doch auch ein FK genauso wie ein PK von Natur aus indexiert oder ?

    Einen Kommentar schreiben:


  • erc
    antwortet
    Zitat von Midget Beitrag anzeigen
    Jetzt stelle ich mir die Frage, da ich ja maximal eine abweichende Lieferadresse pro Kunde akzeptiere, ich nicht sofort die customerID als Primary Key verwenden kann
    Davon hält dich niemand ab. Wenn das Datenmodell so deine Anforderungen erfüllt, spricht da nix dagegen.

    Zitat von Dormilich Beitrag anzeigen
    Wenn du keinen Fremdschlüssel deklarierst, verlierst du die Relation zwischen Kunde und Lieferadresse.
    Du verlierst nicht die Relation. In SQL werden Relationen im Query beschreiben. Was du verlierst sind die constraints. Es hält dich aber auch keiner davon ab, den PK als FK zu definieren.

    Einen Kommentar schreiben:


  • Midget
    antwortet
    ok danke für den Hinweis

    Einen Kommentar schreiben:


  • Dormilich
    antwortet
    Zitat von Midget Beitrag anzeigen
    Hallo,
    Somit würde ich nicht nur eine Spalte (die des zusätzlichen Primary Key) sparen, sondern auch noch das zusätzliche Deklarieren eines Fremdschlüssels.
    Wenn du keinen Fremdschlüssel deklarierst, verlierst du die Relation zwischen Kunde und Lieferadresse.

    Einen Kommentar schreiben:

Lädt...
X