Wieder mal die Tabellenstrukturen

[haentschman]

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

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:

Zitat von haentschman (Beitrag 1372282)

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:

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? :wink:

[Olli73]

Bei einer 1:n-Beziehung Adressen -> Anschriften sollte aber (i.d.R.) die Anschrift auch ein Namensfeld beinhalten, da die entsprechenden Anschriften nicht unbedingt den Kundennamen haben.

Außerdem muss er zusätzlich im Angebot die Anschriften-ID für Liefer- und Rechnungsanschrift speichern, da es ja mehrere geben kann und der User die richtige auswählen muss.

[jobo]

Die originale Anforderung ist meines Wissens mehrere Anschriften zu speichern, aber vielleicht sehe ich den Wald schon länger nicht mehr.
Da ich nicht die Muße habe, auf die Schnelle 60 Beiträge durchzuscannen, wäre mein Vorschlag, der TE sortiert sich und die Beiträge und macht für Einzelprobleme neue Threads auf.
Nicht zu vergessen, zuvor selbst so viel wie möglich umzusetzen und auch auszuprobieren.
Eine komplette CRM / Artikel / Lagerverwaltung in einem Thread durchzuarbeiten ist offenbar nicht zielführend.

[p80286]

Zitat:

Zitat von mikhal (Beitrag 1372281)

Grundsätzlich muss die Kunden-Id in der Anschrift gesetzt werden.

nö kein muss!
Falls n:m Beziehungen vorhanden sein könnten, dann nimmt man eben eine entsprechende Beziehungstabelle.

Gruß
K-H

[p80286]

Zitat:

Zitat von jobo (Beitrag 1372290)

.. oder diese Fälle durch eine flexiblere (mehrfach) Typisierung der Adresse behandeln, nicht aber n Verweisfelder auf die Adresse(n) in den Kundendatensatz eintragen.

Ich kann mich nicht mehr erinnern, ist das wirklich vorgeschlagen worden?

Ansonsten, wäre es wirklich gut wenn der TE sich ein wenig konkretisieren würde, sonst diskutieren wir hier irgendwelche Feinheiten, die für Ihn vollkommen uninteressant sind.

Gruß
K-H

[haentschman]

:P

Zitat:

Falls n:m Beziehungen vorhanden sein könnten, dann nimmt man eben eine entsprechende Beziehungstabelle.

...meine Rede mit der AnschriftLISTEN Tabelle. 8-)

Wie man es auch dreht, es gibt kein allgemeingültiges Muster. Das muß der TE mit seiner Anforderung entscheiden. :wink:

[p80286]

Zitat:

Zitat von haentschman (Beitrag 1372322)

:P

Zitat:

Falls n:m Beziehungen vorhanden sein könnten, dann nimmt man eben eine entsprechende Beziehungstabelle.

...meine Rede mit der AnschriftLISTEN Tabelle. 8-)

hätte ich jetzt nicht so verstanden...

Zitat:

Zitat von haentschman (Beitrag 1372322)

Wie man es auch dreht, es gibt kein allgemeingültiges Muster. Das muß der TE mit seiner Anforderung entscheiden. :wink:

:thumb:

Gruß
K-H

[stOrM]

Ich sag erst mal herzlichen Dank an alle die so fleissig hier geholfen haben! :dp:
Ich versuch jetzt erst mal alles so weit wie es geht zu sortieren und schau mal, wie weit ich komme bzw. auf welche Probleme ich dann stossen werden, dann melde ich mich sicherlich wieder.