windowsfan schrieb:

postleitzahlen sind nicht eindeutig - eine plz kann mehrere ortsteile beinhalten

Deswegen macht das Normalisieren von Postleitzahlen in vielen Ländern (und seit der PLZ-Reform auch in Deutschland) keinen Sinn.
Das Einzige, was du aus einer PLZ-Tabelle ablesen kannst, ist der postalische Ortsname.
Falls du (für Deutschland) den postalischen Ortsnamen wissen möchtest, kannst du zusätzlich die PLZ-Datei der Deutschen Post als Tabelle einbinden.
Der postalische Ortsname ist meist stimmig, oft aber auch irreführend.
Ich kenne Adressen, deren Straßen in dem Ort eines anderen Landkreis liegen als es der Postleit-Ort vermuten lässt.

Die andere Seite ist: Die Adresse muss innerhalb einer Firma nicht eindeutig sein.
Und zusätzlich kann eine Sendungsadresse zur Standortadresse noch Zusatzinformationen enthalten, die die Standortadresse überschreiben.
Und Personen- und Lieferadresse müssen nicht identisch sein.

Beispiel:
Herrn Max Mustermann
Daimler AG Stuttgart
Mercedes-Benz Werk Sindelfingen
D-71059 Sindelfingen
Technology Center
Abt. Werkstoffprüfung 7/33
z.Hd. Herrn Hans Maier
Lieferadresse:
D-71063 Sindelfingen
Benzstraße
Tor 5
Bau 27a

Jetzt fang mal an mit Normieren.

Vielleicht kommt dann so etwas heraus:

Person: ID,Name, Vorname,...,FirmenID, AdressID, Adresszusatz
Firma: ID,Name,...,AdressID
Standort: ID,Name,AdressIDID,FirmenID,...
PLZ: ID,Land,PLZ,Ort
Adresse: ID,PLZID,Ort,Straße,Hausnummer,Postfach,Zusatzinformationen...
Sendung: PersonID(Absender),LieferadressID,Lieferadresszusatz,PersonID(Empfänger)

Du musst also alle möglichen Orte und Adressen für nur eine Sendung auswählen (und das auch noch intelligent).

Fazit: Normalisieren um des Normalisierens willen kann auch ganz schnell zur Farce werden.
Es macht immer Sinn, auch mal das Hirn einzuschalten und auf sinnvolle Anwendung zu achten.

Für eine Lieferadresse würde ich sehr viel mehr Freitext-Felder als Fremschlüssel verwenden.

windowsfan schrieb:

folgende probleme hab ich:

es gibt orte die gleich heißen
postleitzahlen sind nicht eindeutig - eine plz kann mehrere ortsteile beinhalten

Warum ist das ein Problem? Sind schon Daten vorhanden, die du nicht korrekt zuordnen kannst?
Ich meine das ist doch logisch für eine Firma, dass bei einem Hauptsitz verstärkt in der Umgebung Aufträge vergeben werden. Gut - abhängig von welcher Dienstleistung.
Man muss doch also damit klar kommen, dass es manchmal 2 gleiche Kunden im selben Gebiet gibt.

Zu dem letzten Problem, vielleicht findest du eine API, mit der du sämtliche (möglichen) Bundesländer für eine entsprechnde PLZ angezeigt bekommst. Die Daten dann einzupflegen kann ja nicht automatisch gehen, denn woher soll der Computer den wissen, wo genau jetzt der Auftrag vergeben wurde.
Du kannst aber natürlich noch eine Spalte "Bundesland" hinzufügen, denn diese (eindeute) Information wirst du auf jeden fall irgendwie extra brauchen. Angenommen du findest raus, welche beiden Bundesländer möglich wären, dann weiß der Computer ja nicht, in welchem du tatsächlich warst. (Oder er kanns halt mit der Straße über eine API herausfinden).

Ansonsten den Kundenstammdaten auf jeden fall noch eine ID geben.
Dann in jedem Auftrag jeweils die ID des Kundenstammes speichern, sodass du ein 1:m Verhältnis hast, also eine Sendung kann nur einen Kundenstamm haben (oder halt 2 für Empfänger und Absender oder so). Andersherum kann jeder Kundenstamm mehrere Sendungen haben.
So hab ichs jeweils verstanden.

Außerdem wolltest du die Datenbank "so performant wie möglich", vielleicht arbeitest du daher auch mit Indezes.

Ich empfehle dir die VierViews oder vielleicht das EntityFramework. (Beide Links sind ganz okay). EntityFramework generiert dir auch die Datenbank (mit indizes), du kannst aber nicht mit GridViews arbeiten, oder ich hab noch nicht rausgefunden, wie das geht... Vielleicht fängst du mit ersterem an, dein Problem kann man wahrscheinlich mit beidem relativ performant lösen.

Bei sehr großen Datenmengen wirst du wohl Indizes brauchen.

Hey - ihr wundert euch bestimmt schon die ganze Zeit, dass ich noch nicht gesagt habe, dass man solch besser erstmal ohne Datenbank entwirft und entwickelt?
Weil das hier ist wohl der klassische Fall, wo das Datenmodell längst noch nicht in Stein gemeißelt ist, und sich höchstwahrscheinlich noch einige Male ändern wird.

Und da ists nicht wirklich erfreulich, jedes mal die DB neu aufzusetzen, und ein typDataset neu zu generieren, und hoffen, dass man den FolgeFehlern Herr wird.