Wieder mal die Tabellenstrukturen

[stOrM]

Zitat von haentschman:

Moin...

Zitat:

in der Anschrifttabelle gibt es
AnschriftID
KundenID
Anschrifttyp
Strasse,Ort,plz (usw. was man so braucht)

In der Kundentabelle ist die ID der Anschrift doch vorhanden. Deshalb gehört die KundenID hier nicht her. Die Anschrift ist damit für mehrere Kunden "gültig".

Äh wie?
Also ist das jetzt falsch, so wie mir das hier erklärt wurde?

Zitat:

Eine Postleitzahl ist nicht numerisch!
Wären sie das, dann wäre 01234 die gleiche wie 1234.

Also sollte ich die dann als was definieren? Varchar?

Jetzt komm ich grad nicht mit, mal unabhängig davon ob es zu einem Ort mehrere Postleitzahlen gibt, versteh ich das Problem grad nicht so ganz.
Ausgangsfrage war ja erstmal, das Mikhal schrieb, der Ort muss nicht eingetippt werden, sondern kann automatisch gezogen werden, was bei mir nicht funktioniert. Die Frage ist also, warum, hab ich das falsch verstanden oder ist etwas falsch bei mir?

Danach können wir uns ja gern nochmal um das eigentlich Postleitzahl Problem kümmern?
Vielleicht kann ich auch eine separate (Postleitzahlentabelle führen ohne Verknüpfung und den Anwender das quasi als Suche zur Verfügung stellen wo er auswählen kann)
Die Vorwahlen usw. sind unerheblich, trägt der Anwender bei der Telefonnummer ja eh selber ein, das war nur in der Postleitzahlen Tabelle mit dabei, hab ich also drin gelassen, ich hab ja nicht 19.600 Postleitzahlen übers WE manuell eingegeben

[p80286]

Zitat von stOrM:

Zitat:

Eine Postleitzahl ist nicht numerisch!
Wären sie das, dann wäre 01234 die gleiche wie 1234.

Also sollte ich die dann als was definieren? Varchar?

Das wäre eine Möglichkeit, es kommt auf die Datenbank an.

Zitat von stOrM:

Ausgangsfrage war ja erstmal, das Mikhal schrieb, der Ort muss nicht eingetippt werden, sondern kann automatisch gezogen werden, was bei mir nicht funktioniert. Die Frage ist also, warum, hab ich das falsch verstanden oder ist etwas falsch bei mir?

Die reflektionsartige Rückfrage wäre Was funktioniert nicht.
Sobald eine Postleitzahl eingegeben wurde (onChange/CR ?) wird mit
select Ortsname from orttabelle where plz=:plz; Der/die zugehörige(n) Ortsname(n) abgerufen. Diese werden in z.B. einer Listbox zur Verfügung gestellt, oder aber falls es nur einen Datensatz als Antwort gibt, direkt in das Ortsfeld eingetragen. UU kann auch direkt der Link (ortsID) in die Adresstabelle zum aktuellen Datensatz eingetragen werden.
Du siehst, es gibt einige Möglichkeiten. Was davon hast Du wie umgesetzt?

Gruß
K-H

Edith:
Für eine Automatik benötigt man natürlich auch die OrtID:
select Ortsname,OrtID from orttabelle where plz=:plz;

[jobo]

Zitat von stOrM:

Äh wie?
Also ist das jetzt falsch, so wie mir das hier erklärt wurde?

Also komm, Du kannst in einem Forum davon ausgehen, dass es immer mehrere Erklärungen gibt und viele Wege nach Rom führen.
Zusätzlich kannst Du davon ausgehen, dass es Missverständnisse gibt.
Dein Thread ist mittlerweile recht umfangreich, viel Platz für alle Arten von Informationen.

Wir wäre es, die ganzen Infos hier mal umzusetzen und einfach zu sehen, was mit Deinen ID passiert, wenn Du eine oder mehrere Adressen eintragen möchtest. Alternativ das Szenario mal durchdenken.
Und dann solltest Du die Frage eigentlich selber beantworten können, weil sie ein immer wiederkehrendes Muster in den Verbindungen zwischen den Tabellen darstellt.

[haentschman]

Moin...

Zitat:

Äh wie?
Also ist das jetzt falsch, so wie mir das hier erklärt wurde?

...wie schon gesagt wurde, führen viele wege nach Rom.

Mein Einwand "die KundenID gehört nicht in die Adresstabelle":
Stell dir mal vor es gibt in der Stadt X ein Bürohochhaus. In diesem wohnen deine Kunden. Jetzt mußt du für jeden Kunden einen Datensatz in die Adresstabelle einpflegen weil der Datensatz die ID des Kunden trägt. Ohne die KundenID wäre es ein Datensatz für alle Kunden die da wohnen. Der Kunde selbst kennt seine Adresse (AdressID aus der Adresstabelle)...fertsch.

[mikhal]

Grundsätzlich muss die Kunden-Id in der Anschrift gesetzt werden. Wird die Anschrift-Id im Kunden gesetzt, kann ich nur noch eine Anschrift zuordnen, eine Unterscheidung nach Liefer-, Rechnungs- oder abweichender Anschrift ist dann nicht mehr möglich.

Grüße
Mikhal

[haentschman]

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.

[mikhal]

Ich arbeite im Großhandel. Folgendes Szenario ist bei uns Standard: Eine Fachhändler bestellt bei uns Ware und lässt die ohne Umwege direkt bei seinem Kunden anliefern. Bilde diese Anforderung an die Anschrift in deinem Modell ab.

Grüße
Mikhal

PS: Auch eine Rechnungsanschrift kann falsch sein. Wenn autarke Filialen ins Spiel kommen, benötigst du ggf. auch mehrere Rechnungsanschriften...

[haentschman]

Hallöle...
Das du mit einem Großhandel andere Probleme hast ist klar. Wir müssen das auf das einfache Problem herunterbrechen.

Zitat:

Bilde diese Anforderung an die Anschrift in deinem Modell ab.

Da hätte ich nur eine AnschriftLISTEN Tabelle zwischen der Originalen Adressliste und dem Kunden eingebaut. Diese Tabelle hällt nur die Beziehungen zwischen den Kunden und den eigentlichen Adressen und die ID des AdressTyps. Da gehört selbstverständlich die KundenID mit rein.

@TE...je nach Anforderung können auch die Tabellenschemata unterschiedlich sein.

[jobo]

Zitat von haentschman:

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.

[haentschman]

Zitat:

nicht aber n Verweisfelder auf die Adresse(n) in den Kundendatensatz eintragen.

Wenn die Anforderung 1:n ist dann logischerweise nicht. Wenn das Angebot beim TE nur eine Adresse beinhaltet ist es legitim.

Wie schaut die originale Anforderung aus?