DBdesign einer 1:1 Beziehung

[khh]

hallo zusammen,

ich habe der Übersichtlichkeit halber einige Felder meiner Tabelle Kunden in eine Tabelle Zahlungsbedingungen ausgelagert.
Jetzt bin ich mir nicht sicher, soll/ muss ich die id der zahlungsbedingungen(primärschlüssel) beim kunden, oder die Kundennummer(Primärschlüssel) bei den Zahlungsbedingungen speichern.
Eigentlich ists ja egal, aber wie ists nach den Normalisierungsregeln richtig?


danke gruss Kh

[Codewalker]

Afaik ist doch eine 1:1-Beziehung gar nicht normalisiert/normalisierbar gemäß der üblichen Regeln, weil die nur 1:n und n:m-Beziehungen betreffen. Vielmehr sollte man sich fragen, warum man das Feld nicht direkt in die Tabelle dazupackt (Übersichtlichkeit wäre da imho das kleinste Argument - dann lieber die Doku oder Oberfläche für den Zugriff verbessern)

[khh]

in einer alten Info habe ich folgendes gefunden:

Mit einer 1:1-Beziehung kann eine Zeile in Tabelle A nur mit einer Zeile in Tabelle B verknüpft werden und umgekehrt. Eine 1:1-Beziehung wird erstellt, wenn es sich bei beiden verknüpften Spalten um Primärschlüssel handelt oder beide UNIQUE-Einschränkungen besitzen.

Dieser Beziehungstyp wird nur selten verwendet, da sich Informationen, die in dieser Weise miteinander verbunden sind, meist in ein und derselben Tabelle befinden. Sie können eine 1:1-Beziehung bei folgenden Vorgänge verwenden:

* Teilen einer Tabelle mit vielen Spalten
* Isolieren eines Teils der Tabelle aus Sicherheitsgründen
* Speichern von Daten mit kurzer Lebensdauer, die gelöscht werden können, indem Sie einfach die Tabelle löschen
* Speichern von Informationen, die nur für eine Teilmenge der Haupttabelle gültig sind


ich würde beispielsweise auf jeden Fall diverse sensible Daten z.B.(Lohn/Gehalt) , eben aus Sicherheitsgründen separieren.

Bei den Zahlunsbedingungen _könnte_ es sich ebenfalls um solche handeln.


Gruss KH

[mjustin]

Zitat von khh:

hallo zusammen,

ich habe der Übersichtlichkeit halber einige Felder meiner Tabelle Kunden in eine Tabelle Zahlungsbedingungen ausgelagert.
Jetzt bin ich mir nicht sicher, soll/ muss ich die id der zahlungsbedingungen(primärschlüssel) beim kunden, oder die Kundennummer(Primärschlüssel) bei den Zahlungsbedingungen speichern.
Eigentlich ists ja egal, aber wie ists nach den Normalisierungsregeln richtig?

Semantisch handelt es sich bei den Zahlungsbedingungen um eine Detailtabelle zur Kunden-Mastertabelle mit (maximal) einem Satz, daher würde ich die zweite Variante wählen.
Dadurch ist es allerdings auch möglich, mehrere Zahlungsbedingungen einem Kunden zuzuordnen.

Nur falls eine Zahlungsbedingung auch mehreren Kunden zugeordnet werden können soll (also 1:M), würde ich deren ID in der Kundentabelle hinterlegen.

[khh]

Zitat von mjustin:

Zitat von khh:

hallo zusammen,

ich habe der Übersichtlichkeit halber einige Felder meiner Tabelle Kunden in eine Tabelle Zahlungsbedingungen ausgelagert.
Jetzt bin ich mir nicht sicher, soll/ muss ich die id der zahlungsbedingungen(primärschlüssel) beim kunden, oder die Kundennummer(Primärschlüssel) bei den Zahlungsbedingungen speichern.
Eigentlich ists ja egal, aber wie ists nach den Normalisierungsregeln richtig?

Semantisch handelt es sich bei den Zahlungsbedingungen um eine Detailtabelle zur Kunden-Mastertabelle mit (maximal) einem Satz, daher würde ich die zweite Variante wählen.
Dadurch ist es allerdings auch möglich, mehrere Zahlungsbedingungen einem Kunden zuzuordnen.

Nur falls eine Zahlungsbedingung auch mehreren Kunden zugeordnet werden können soll (also 1:M), würde ich deren ID in der Kundentabelle hinterlegen.

ich danke euch,
so werd ichs machen, die kdnummer bei den Zahlungsbedingungen

Gruss KH

[alzaimar]

Die Kundennummer sollte NIE der PK sein. Verwende ein nichtsprechendes unsichtbares Feld, z.B. eine 'KundenID', die als AutoInc implementiert ist. Eine Kundennummer (oder Artikel- Lieferanten- usw. -Nummer) ist UNIQUE, aber niemals der PK. Denn Kundennummern ändern sich. Immer wieder beliebt ist die Neuvergabe, weil plötzlich alle Kunden 8-stellige Nummern erhalten sollen. Viel Spass beim Nachpflegen der Tabellen.

[khh]

Zitat von alzaimar:

Die Kundennummer sollte NIE der PK sein. Verwende ein nichtsprechendes unsichtbares Feld, z.B. eine 'KundenID', die als AutoInc implementiert ist. Eine Kundennummer (oder Artikel- Lieferanten- usw. -Nummer) ist UNIQUE, aber niemals der PK. Denn Kundennummern ändern sich. Immer wieder beliebt ist die Neuvergabe, weil plötzlich alle Kunden 8-stellige Nummern erhalten sollen. Viel Spass beim Nachpflegen der Tabellen.

da gebe ich dir recht.
Ursprünglich war auch eine id der PK.
Aus einem mir im Moment nicht nachvollziebaren Grund wurde aber die Kundennummer zum PK.
Muss ich mir wirklich nochmal genauer anschauen.

Ich danke dir für den wichtigen Hinweis mit der Neuvergabe.

Gruss Kh

[hoika]

Hallo,

Ändern der Kundennummer sollte aber die Nummer in allen referenzierten Tabellen
automatisch ändern (cascade update).

Aber du hast auf jeden Fall Recht, nie etwas als foreign key benutzen,
was der Anwender ändern kann.


Zur eigentliche Frage:
Ich würde eine m:n Beziehung machen, also 3 Tabellen
Kunde, Zahlungsbedingung, Kunde-Zahlungsbedingung

Zahlungsbedingungen sind doch auch normale Sachen,
die mehrere Kunden gleichzeitig haben können (z.B. "4 Wochen nach Rechnungserhalt").


Heiko

[khh]

ich danke euch für eure meinungen


Gruss Kh

[sx2008]

Zitat von hoika:

Ich würde eine m:n Beziehung machen, also 3 Tabellen
Kunde, Zahlungsbedingung, Kunde-Zahlungsbedingung

Zahlungsbedingungen sind doch auch normale Sachen,
die mehrere Kunden gleichzeitig haben können (z.B. "4 Wochen nach Rechnungserhalt").

Also ich bin kein Buchhalter, aber ein Kunde kann doch nur eine bestimmte Zahlungsbedingung haben, oder?

Code:

IdZahlBed Zahlungsbedingung
===========================
1         Vorkasse
2         Nachnahme
3         auf Rechnung (30 Tage)
5         auf Rechnung (innerhalb 2 Tagen 2% Skonto, spätestens nach 14 Tagen muss bezahlt werden)
6         Kreditkarte (Visa)
7         Kreditkarte (Mastercard)
8         Ratenzahlung

Das wäre dann eine 1 : N Beziehung.
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.