|
Datenbank: firebird • Version: 2.1 • Zugriff über: zeos
DBdesign einer 1:1 Beziehung
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 |
Re: DBdesign einer 1:1 Beziehung
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)
|
Re: DBdesign einer 1:1 Beziehung
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 |
Re: DBdesign einer 1:1 Beziehung
Zitat:
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. |
Re: DBdesign einer 1:1 Beziehung
Zitat:
so werd ichs machen, die kdnummer bei den Zahlungsbedingungen Gruss KH |
Re: DBdesign einer 1:1 Beziehung
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.
|
Re: DBdesign einer 1:1 Beziehung
Zitat:
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 |
Re: DBdesign einer 1:1 Beziehung
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 |
Re: DBdesign einer 1:1 Beziehung
ich danke euch für eure meinungen
Gruss Kh |
Re: DBdesign einer 1:1 Beziehung
Zitat:
Code:
Das wäre dann eine 1 : N Beziehung.
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 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. |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 05:08 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz