Delphi-PRAXiS
Seite 5 von 6   « Erste     345 6      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Datenbanken (https://www.delphipraxis.net/15-datenbanken/)
-   -   Wieder mal die Tabellenstrukturen (https://www.delphipraxis.net/192769-wieder-mal-die-tabellenstrukturen.html)

haentschman 21. Mai 2017 08:36

AW: Wieder mal die Tabellenstrukturen
 
Moin...:P
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". 8-)

p80286 21. Mai 2017 08:37

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

Gruß
K-H

jobo 21. Mai 2017 09:41

AW: Wieder mal die Tabellenstrukturen
 
Zitat:

Zitat von hstreicher (Beitrag 1372201)
es gibt hier einen großen Denkfehler bzgl der Postleitzahlen:
Eine Postleitzahl kann durchaus mehrere Orte umfassen

http://www.gutefrage.net/frage/eine-...eine-bestimmte

mfg Hannes

Auch eine Vorwahl kann sich innerorts (PLZ) unterscheiden. abhängig von alten Kupfernetzen aus Postzeiten, Gebietsreformen etc. pp. Hier driftet Realität und Idealmodell soweit auseinander, dass es ggF. ratsam ist, die Nachschlagetabelle nicht zur Verknüpfung einzusetzen, sondern als "Lieferant" korrekter Werte, Stichwort Datenqualität.
Die Möglichkeit, dass die "Vorwahl" der Anschrift nicht ein Festnetzanschluss, sondern ein Handy ist, macht es auch nicht einfacher.
Die Perspektive, das Datenmodell hier irgendwann international einzusetzen, macht es noch weniger einfach.

stOrM 21. Mai 2017 19:50

AW: Wieder mal die Tabellenstrukturen
 
Zitat:

Zitat von haentschman (Beitrag 1372202)
Moin...:P
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". 8-)

Ä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 :-D

p80286 21. Mai 2017 20:56

AW: Wieder mal die Tabellenstrukturen
 
Zitat:

Zitat von stOrM (Beitrag 1372260)
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:

Zitat von stOrM (Beitrag 1372260)
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
SQL-Code:
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:
SQL-Code:
select Ortsname,OrtID from orttabelle where plz=:plz;

jobo 22. Mai 2017 05:21

AW: Wieder mal die Tabellenstrukturen
 
Zitat:

Zitat von stOrM (Beitrag 1372260)
Ä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 22. Mai 2017 06:09

AW: Wieder mal die Tabellenstrukturen
 
Moin...:P
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. :P

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. :thumb: Der Kunde selbst kennt seine Adresse (AdressID aus der Adresstabelle)...fertsch. 8-)

mikhal 22. Mai 2017 07:55

AW: Wieder mal die Tabellenstrukturen
 
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 22. Mai 2017 08:03

AW: Wieder mal die Tabellenstrukturen
 
Zitat:

...wie schon gesagt wurde, führen viele wege nach Rom.
...8-)
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. :P 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. :thumb:

mikhal 22. Mai 2017 08:31

AW: Wieder mal die Tabellenstrukturen
 
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...


Alle Zeitangaben in WEZ +1. Es ist jetzt 19:35 Uhr.
Seite 5 von 6   « Erste     345 6      

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz