Steuerinformationen zu Datensatz in der selben Tabelle oder über 1:n-Relation

[Aurelius]

Hallo zusammen,

ich habe eine prinzipielle Frage zum Datenbank-Design und hätte da gerne ein paar Drittmeinungen.

Ich habe eine Tabelle, bspw. KUNDEN (alle Bezeichnungen sind nur Beispiele). Nun möchte ich für jeden Datensatz verschiedene Boolean-Steuerinformationen hinterlegen, welche Auswirkungen in diversen anderen Programmteilen haben (bspw. VIPKUNDE, KOMMUNIKATIONSSPERRE, MAHNSPERRE...). Klassischerweise ist das eine 1:1-Beziehung, ergo kann ich diese Daten direkt in der Tabelle KUNDEN hinterlegen.

Nun habe ich aber nicht nur einige wenige solcher Steuerinformationen, sondern einen ganzen Haufen voll. Im Laufe der Zeit kommen auf Kundenwunsch diverse andere Felder hinzu. Die Tabelle erhält somit immer mehr Felder und wird irgendwann unübersichtlich. Zusätzlich muss ich jedesmal die Oberfläche anfassen und die Felder zur Verfügung stellen.

Eine Alternative wäre, aus diesen Steuerinformationen einfach eine 1:n-Beziehung zu erstellen. Neue Tabelle KUNDENSTEUERINFORMATION mit den Spalten BEZECHNUNG und TYP (enthält per Enum die möglichen Informationen) und dazu eine Mapping-Tabelle KUNDEN_STEUERINFORMATIONEN_ZUORDNUNG. Bei einer entsprechend designten Oberfläche kann ich die Informationen nun vergleichsweise einfach (dynamisch) erweitern, zusätzlich blähe ich meine Haupttabelle nicht unnötig auf.

Was ist eure Meinung zu dieser Problematik? Laut Normalformen würden ja beide Varianten funktionieren.

[mkinzler]

Da es sich um eine n:m-Beziehung handelt würde ich das durch 3 Tabellen Lösen:

KUNDEN
ID
...

STATUS
ID
BEZ
...

KUNDENSTATI
ID
KundeID
STATUSID
Aktiv

[jobo]

Kann ich nur empfehlen. Ich würde allerdings noch etwas in die Datenhaltung investieren und die Infos ggF als XML Schnippsel inkl. XSD anlegen. Damit hast Du dann noch komfortable Möglichkeiten, die Eingabe zu validieren.

[mkinzler]

Zitat:

Laut Normalformen würden ja beide Varianten funktionieren.

Beim ersten Fall aber nur die 1.

[Mavarik]

OK! Old School...Auch auf die Gefahr hin, dass die Datenbank Freaks über mich herfallen...

Ich stehe oft vor der gleichen Frage...

Historisch gesehen habe ich es immer so gemacht, dass mein Record auf die nächste 2er Potenz verlängert habe.

Delphi-Quellcode:

Kunden = Record
           Name : String[40];
           ...
           Frei : Array[1024-(650+Sizeof(Whatever))] of Byte;
         end;

So konnte ich immer sehr schön Sektororientiert auf die Platte schreiben.

Das Konzept habe ich beibehalten.

Meine Datenbanken haben am Ende immer ein Blobfeld. Hier schreibe ich - wenn ich es brauche - gezipt erweiterte Information rein.
(Unter der Voraussetzung, dass ich diese nicht für ein Select,Sort usw. benötige)

Hab mir einfach eine generelle Routine dafür geschrieben... Fertig... Erweiterungen kein Thema...

Daher bin ich für Änderungen immer offen.

Zum Redesign Deiner Anwendung:

Ich Redesigne in so einem Fall IMMER... Die alternative wäre die Informationen in einem Grid darzustellen...
Das ist für mich ein absolutes NOGO... Nur Listen gehören in ein Grids... Nie Eingaben.

Mavarik

[Aurelius]

@ mkinzler:
Genau so einen Aufbau mit 3 Tabellen habe ich gemeint.
Aber bist du dir sicher dass die erste Variante die 2. Normalform etc. verletzt? Schließlich sind die Steuerinformationen ja nur abhängig vom Primary Key.

ID	Name	...	VIPKUNDE	MAHNSPERRE
1	Müller	...	1	0
2	Maier	...	0	0
3	Werner	...	1	1

@ Mavarik:
Warum ist eine dynamische Erfassung für dich so ein NoGo? Ich finde die eigentlich annehmbar

@ all: Danke für die Rückmeldungen

[Mavarik]

Zitat von Aurelius:

@ Mavarik:
Warum ist eine dynamische Erfassung für dich so ein NoGo? Ich finde die eigentlich annehmbar

Verteile Tabelle sind wie verteilte Datei...

Inkonsistenzen sind vorprogrammiert. Tabelle A wird upgedatet Tabelle B nicht Daten passen nicht mehr zusammen...
Eine Exception an der falschen Stellen... (Ja es gibt Transaktionen...)

Ein User kopiert eine Datei von a noch b oder nur eine Tabelle...

Alles unnötige Fehlerquellen - Einfach meine Erfahrung der letzten 34 Jahre Programmierung.

Eingabe in einem Grid? Vielleicht Deine..., aber meine Kunden können da nicht mit umgehen.

Die brauchen

Label: Edit
[ ] Checkcaption
Combobox [Speedbutton]

[&Speichern] [&Abbrechen]

Und nicht etwa ein DBNavigator mit Post & Refresh...

[DeddyH]

Zitat von Mavarik:

Inkonsistenzen sind vorprogrammiert. Tabelle A wird upgedatet Tabelle B nicht Daten passen nicht mehr zusammen...

Dann solltest Du Dein DB-Design aber noch einmal sehr gründlich überdenken. RDBMS sind ja eben dafür erdacht worden, damit so etwas nicht passieren kann.

[jobo]

Zitat von DeddyH:

Dann solltest Du Dein DB-Design aber noch einmal sehr gründlich überdenken. RDBMS sind ja eben dafür erdacht
worden, damit so etwas nicht passieren kann.

Vermutlich hat er das. Ich habe ihn so verstanden, dass es ein allgemeiner Beitrag zu seinen schlechten Erfahrungen war.
Aber Du hast Recht, letzlich dürfte genau das "beim Update vergessen" mit einem richtigen DM bei redundanzfreier Datenhaltung nicht passieren.

[jobo]

@Aurelius: Hast Du im Arbeitsvertrag stehen, dass Du niemals die Normalform verletzen darfst?
So eine Diskussion ist auf dieser Ebene m.E. müßig, bzw. gibt es bei Deiner Idee wichtigere Fragen. Wieviele Systeme gibt es, die bspw. explizit PLZ und Stadt abspeichern?
U.a. kann man sich vielleicht streiten, ob die Relationstabelle einen eigenständigen Primärschlüssel bekommt, wie vorgeschlagen oder ob die beiden Fremdschlüssel reichen, m.E. Geschmackssache.

Dymamische Anzeige/ Eingabe ist eine reine Kosten / Nutzen Geschichte. Wenn der Kunde zahlt, machst Du das Feld eben in die Maske rein. Wenn Du keine Lust und oder keine Zeit hast, obwohl der Kunde zahlt, tja..
Aber dann gibt es da Dinge, die würde ich von Fall zu Fall genau überlegen.

Beispiel Mahnsperre: Es kommt mir so vor, als ob das eine relativ zentrale Bedeutung für den ein oder anderen Business Case hat und das würde ich nicht unbedingt irgendwo unter ferner liefen abfackeln.
Oder anders: Wenn es um Inhalte geht, die meine eigene Anwendung nutzt, auswertet und sich jenachdem anders verhält, würde ich eine hohe Bindung an die Kernobjekte bevorzugen.
Sind es dagegen "irgendwelche" Kundendaten, die vielleicht sogar selbst beim Kunden nur importiert werden, nie oder selten angefasst werden und nur für einen weiteren DL gehalten und dann exportiert werden, würde ich das sehr gern "weiter weg" lagern.