Zitat:
...wie schon gesagt wurde, führen viele wege nach Rom.
...
Zitat:
Grundsätzlich muss die Kunden-Id in der Anschrift gesetzt werden
...sehe ich anders. Der Kunde hat eine ID für die Anschrift, eine ID für die Rechnungsanschrift, eine ID für was auch immer.
Persönlich würde ich die Adressen nicht mit der KundenID verküpfen. Da hast du viel zu viele redundante Felder. Wenn sich alle Kunden eine Lieferanschrift teilen (Packstation) hast du für jeden Kunden doppelte Einträge. Da ist es besser das Pferd anders herum aufzuzäumen.
Das ist mir zu schräg, selbst wenn viele Wege nach Rom führen, kann man gerne den gut ausgebauten "Highway" nehmen.
Die normalisierte Variante 1 Kunde hat N Adressen (mit unterschiedlichen Verwendungszwecken) ist der Weg, den ich nach Rom empfehle, analog zu Mikhal. Dies gilt nicht nur fachlich speziell für die Adressen hier, sondern generell auch nach den gängigen Modellierungsverfahren unabhängig vom Inhalt der Daten.
Also, die Adresse hält die Referenz auf den Kunden. Andere Verfahren würde ich als "speziell", Bastellösung oder ungewöhnlich bezeichnen.
Zum Thema Redundanz:
Redundanzfreiheit bei der Datenmodellierung dreht sich nicht darum, ein Bytes Daten zu sparen. Die paar Adressen auf der Packstation, geschenkt.
Ich will diesen Thread nicht noch komplexer machen, aber wenn man wirklich die Mehrfacherfassung identischer Adressen vermeiden will/muss, würde man wohl mit einer N:M Relation arbeiten oder diese Fälle durch eine flexiblere (mehrfach) Typisierung der Adresse behandeln, nicht aber n Verweisfelder auf die Adresse(n) in den Kundendatensatz eintragen.