DBdesign einer 1:1 Beziehung

[khh]

Zitat von sx2008:

Wenn man's genau nimmt, muss doch die Zahlungsbedingung bei der Bestellung gespeichert werden.
Häufig: die erste Bestellung geht per Vorkasse, alle weiteren auf Rechnung.
Die Zahlungsbedingung in der Kundentabelle wäre dann nur der Default für Bestellungen in der Zukunft.

richtig,
die Zahlungsbedingungen beim Kunden sind default-werte, die je nachdem bei der Bestellung überschrieben werden können.

Gruss Kh

[sx2008]

Zitat von khh:

die Zahlungsbedingungen beim Kunden sind default-werte, die je nachdem bei der Bestellung überschrieben werden können.

Dann ist die Sache ja klar:
Es gibt folgende Beziehungen:
Kunden <-> Zahlungsbedingungen (1 : N)
Bestellungen <-> Zahlungsbedingungen (1 : N)
Die Tabellen Kunden und Bestellungen enthalten jeweils einen Fremdschlüssel auf die Tabelle Zahlungsbedingungen.
Bei der Kundentabelle ist NULL im dem Fremdschlüsselfeld erlaubt (bedeutet: es wurde keine Default Zahlungsbedingung vereinbart), bei der Tabelle Bestellungen ist NULL nicht erlaubt.

[WInfo]

Moin, Moin,

denke SX2008 geht schon in die richtige Richtung, aber für was benötigt man eine Zahlungsbedingung, wenn bereits bezahlt ist?

In aller Regel hat man vielleicht 1 Dutzend Zahlungsbedingungen, plus ggf. ad-hoc Zahlungsbedingungen, wenn man diese später noch auswerten möchte, tut man gut daran, diese in eine eigene Relation auszulagern. Da sich die vereinbarten Zahlungsbedingungen mit einem Kunden (Vertragsbestandteil) im laufe der Zeit ändern können, sollten diese in den Vertrag vererbt werden, damit die Historie für Auswertungen bestehen bleibt. Damit ergibt sich das ERM lt. Anhang.

Die Beziehungen der Zahlungsbedingungen, zeigen dass diese im jeweiligen Kunden resp. Vertrag zu hinterlegen ist. Werden Spezialbedingungen vereinbart, entziehen sie sich der Auswertung, daher kann auch ein Vertrag (auch Zielkauf) keine Zahlungsbedingung aufweisen, hier wäre dann die Spezialkondition direkt in den Vertrag aufzunehmen.

That's my 2c

[alzaimar]

Ein sehr guter Einwand. Für historische Auswertungen sind jedoch auch andere Eigenschaften des Kunden interessant, die sich im Laufe der Zeit ändern können, z.B. die Adresse (Auswertung nach PLZ), Rabattierung, Preislisten etc.