Querys mit Foreign Keys

verwendetes Datenbanksystem: MySQL

Guten Tag, und zwar lerne ich gerade, wie ich eine Datenbank mit der 3. Normalform realisieren kann.

Dazu habe ich nun folgendes Beispiel:

Tabelle: User
Spalten:

• UserID (PRIMARY KEY, AUTO_INCREMENT)
• Vorname
• Nachname
• PLZ (INDEX, Foreign Key mit PLZ aus Postleitzahl)

Tabelle Postleitzahl

• PLZ (PRIMARY KEY)
• Ort

1. Frage:
   Ich habe ein ganz normales User Erstellungsformular (Vorname, Name, PLZ, Ort).
   Wenn ich die Daten nun absende, wie verhält sich das dann? Prüft MySQL automatisch, ob ein Eintrag mit eingegebener PLZ vorhanden ist? Und was passiert, wenn die PLZ noch nicht existiert ? Muss ich selber mittels Querys prüfen, ob die PLZ vorhanden ist und wenn nicht, dann füge PLZ + Ort in die Postleitzahl Tabelle ein ?
   Wie geht man mit Fremdschlüsseln um ?

2. Frage
   Wenn ich einen Kunden nun auslesen möchte, bekomme ich nur die PLZ heraus. Wie kann ich gleichzeitig auch den Ort mit angeben ? Ist ein LEFT JOIN nötig, oder wie macht man so etwas am besten mit Fremdschlüsseln?

Ich habe mir die 3. Normalform angeschaut und weiß nun, dass man alles trennen sollte und mehre Tabellen anlegen sollte. Dies habe ich in der oben genannten Datenbank getan.

Wie allerdings muss ich nun meine Querys schreiben?
Also was genau ist nun Vorteilhaft, die 3. NF zu benutzen? Klar, es soll Performanter sein und doppelte Einträge vermeiden.
Aber verstehe ich aktuell noch nicht, was passiert / was man macht wenn wie bspw. in den oben genannten Fragen, bestimmte Einträge noch nicht vorhanden sind.

Ich arbeite gerade an meinem IHK Abschlussprojekt, wo ich ein ER Modell in 3. NF erstellt habe.
Ich habe also sehr viele Tabellen getrennt und ausgelagert. Frage mich aber nun, wie ich das in der Praxis (Querys) verwende (Siehe Anhang)

Adressen haben Besonderheiten, weshalb diese sich nicht so einfach normalisieren lassen.

• Eine PLZ kann auf mehrere Orte verweisen (vor allem in ländlichen Gebieten); Beispiel 35094 Lahntal und 35094 Marburg
• Ein Ort kann mehrere PLZ haben (gerade größere Städte)

Daher lassen sich Adressen auch nicht in dieser Form normalisieren.
Dein Schema würde hier knallen.

Unique geht nur das Feld-Paar "PLZ" und "Ort" gemeinsam.
Daher kann PLZ alleine auch nicht der Key sein.

1. Eine Datenbank schenkt Dir prinzipiell nichts. Du musst alles selbst umsetzen.
   Das ist Aufgabe der Anwendungslogik; nicht die der Datenbank.

2. Ja, dafür verwendet man JOINS - erübrigt sich aber nach der Tatsache, dass man so Adressen nicht normalisieren kann

In der Regel hast Du weitere Themen, wenn Du von Kunden sprichst:

• Ein Kunde kann mehrere Adressen haben (Beispiele: Lieferadresse, Rechnungsadresse, mehrere Standorte...)
• Wenn ein Kunde eine Bestellung ausführt, dann muss es hier eine gewollte Redundanz geben. Eine Adresse einer Bestellung darf sich im nachhinein nicht mehr ändern lassen (zB. weil der Kunde 2 Jahre nach der Bestellung umgezogen ist...)

Hast Dir hier wohl ein paar Fallstricke selbst gebastelt 😉

Ah okay, dann habe ich mich anhand folgenden Beispieles irritieren lassen.

Das heißt, dass ich den Ort wieder in die User Tabelle einfügen sollte ?

Wer auch immer das Beispiel gemacht hat, kennt wohl die kuriosen Realitäten der Post-Welt in Deutschland nicht 😉

Das heißt, dass ich den Ort wieder in die User Tabelle einfügen sollte ?

In den meisten Fällen macht man das so, ja.

Okay, danke dir.

Ich habe mich auf dieser Seite belesen: http://www.datenbanken-verstehen.de/datenmodellierung/normalisierung/dritte-normalform/

Wo auch der Screenshot zu finden ist.

Inhaltlich hat er prinzipiell recht; nur speichert man i.d.R. keine Werte mit führenden Nullen als Integer - und ebenso ist das Beispiel mit PLZ Unique halt ungünstig.