Wie Datenbankstruktur aufbauen ?

[RWarnecke]

Hallo zusammen,

ich habe zwei Fragen, wie würdet Ihr bei folgender Situation die Datenbankstruktur aufbauen ?

Situation:

• Im ersten Tab werden Kundendaten erfasst mit einer eindeutigen Kundennummer, die es nur einmal gibt.
• Drei Tabs in der Eingabemaske (Tab1, Tab2, Tab3)
• Der dritte Tab wird nur angezeigt, wenn im zweiten Tab eine entsprechende Auswahl getroffen wurde. Die Daten müssen auch dann nur gespeichert werden, wenn der dritte Tab angezeigt wird.
• Auf dem zweiten und dritten Tab habe ich mehrere Bereiche wo bis zu 30 Checkboxen vorhanden sind.
• Alle Daten von allen drei Tabs müssen bei der Anzeige immer geladen werden. (Tab3 nur dann wenn die Voraussetzung von Tab 2 gegeben ist)

Fragen:

1. Wie würdet Ihr die drei Tabs in Datenbanktabellen aufteilen ?
2. Wie würdet Ihr die Bereich mit den bis zu 30 Checkboxen innerhalb der Datenbanktabelle anlegen ?

[Uwe Raabe]

In der Regel sollte die visuelle Darstellung nicht als Grundlage für die Datenbankstruktur dienen. Auch die Aussage

Zitat:

Zitat von RWarnecke (Beitrag 1378155)

Der dritte Tab wird nur angezeigt, wenn im zweiten Tab eine entsprechende Auswahl getroffen wurde. Die Daten müssen auch dann nur gespeichert werden, wenn der dritte Tab angezeigt wird.

rechtfertigt nicht zwingend eine separate Tabelle mit den Daten von Tab 3 mit einer 1:1 Beziehung zur Kundentabelle. Das lässt ich auch noch problemlos in einer einzigen Tabelle mit entsprechenden NULL-Feldern realisieren.

Bei den Checkboxen kommt es darauf an, ob du nach einzelnen Checkbox-Werten auswerten wills oder nicht. Im letzteren Fall kann man die auch als Bitmuster-Feld hinterlegen um Platz zu sparen. Einfacher und bequemer sind allerdings einzelne Bool-Felder. Je nach Datenbank kann man auch über Array-Felder nachdenken.

[RWarnecke]

Zitat:

Zitat von Uwe Raabe (Beitrag 1378156)

rechtfertigt nicht zwingend eine separate Tabelle mit den Daten von Tab 3 mit einer 1:1 Beziehung zur Kundentabelle. Das lässt ich auch noch problemlos in einer einzigen Tabelle mit entsprechenden NULL-Feldern realisieren.

Welche Nachteile oder Vorteile hat eine separate Tabelle gegenüber wenn ich alles in eine Tabelle packe ?

Zitat:

Zitat von Uwe Raabe (Beitrag 1378156)

Bei den Checkboxen kommt es darauf an, ob du nach einzelnen Checkbox-Werten auswerten wills oder nicht. Im letzteren Fall kann man die auch als Bitmuster-Feld hinterlegen um Platz zu sparen. Einfacher und bequemer sind allerdings einzelne Bool-Felder. Je nach Datenbank kann man auch über Array-Felder nachdenken.

Die Checkboxen sind reine Multiple-Choice Bereiche. Ich muss nur den Status der Checkbox speichern, sobald er sich ändert und natürlich auch wieder anzeigen, wenn die Maske aufgerufen wird.

[mensch72]

aus meiner Sichr sinnvolle DB Struktur:
- BasisDaten ala Kundennummer und Kundenname (PK) plus die Daten aus "Tab1" und "Tab2" in die Haupttabelle
- die Daten des "Tab3" wenn vorhanden in eine 1:1 per KundenNr verknüpfte separate "DetailTabelle"
- in der DB per referenzieller Integritätsregel dafür sorgen, das wenn ein Datensatz der Haupttabelle gelöscht wird, automatisch auch ein eventueller Datensatz in der Detailtabelle verschwindet

Das Abspeichern von 30 CheckboxFeldern in einer DB hängt davon ab, wie elegant du rein per SQL zuküntig darauf "filtern" willst.
- faule TMS Anwender nehmen "DBAdvOfficeCheckGroup"
- 30 BoolFelder (sehr unschön)
- ein TextFeld mit 30 '0'/'1' (OldScool und sogar MultiState-Fähig['0'/'1'/'2'/..], für den Fall das plötzlich doch mal schnell noch eine Zusatzinfo gespeichert werden muss)
- wer keinen Platz bei Milionen von Datensätzen verschwenden will, nimmt ein 32Bit oder 64Bit Ganzzahlfeld oder ein 128Bit GUID-Feld und setzt sich im Delphi das bitweise zusammen, da ist dann aber nix mehr mit Filtern per StandardSQL
- wenn man es rein DB technisch lösen möchte, nehme man eine zusätzliche N:M Verknüpfungstabelle, wo mindestens KundenNr+CkeckBoxNr als Felder drin sind, und die Existenz/nich Existenz des Verküpfungsdatensatzes dann den CheckBox State repräsentiert... erweitert gäbe es noch ein "LinkValue", womit man dann dann auch wieder "MultiState-Fähig" wäre


Die meisten Anwendungen die ich kenne, nehmen Textfelder passender Länge gefüllt mit '0'/'1', oder nutzen sauber eine separate N:M LinkTabelle.
Ich selbst programmiere wenn es um wirklich viele Datensätze geht auch gerne mit Ganzzahlfeldern die ich selbst BitWeise auswerte oder zusammensetze.


Anbei ein total OldScool Quick&Dirty GUI dazu, was ich für so Sachen mir so angewöhnt habe... bleibt aber selten optisch auf Dauer so;)

[Uwe Raabe]

Zitat:

Zitat von RWarnecke (Beitrag 1378157)

Welche Nachteile oder Vorteile hat eine separate Tabelle gegenüber wenn ich alles in eine Tabelle packe ?

Vorteil: keine Verschwendung von Speicherplatz. Ist aber wohl nur dann relevant, wenn der Anteil der Tab3-Records klein ist gegenüber der Anzahl der Kundenrecords.
Nachteil: erhöhter Verwaltungsaufwand beim Abspeichern.

Beim Lesen würde man das wohl eh über einen JOIN realisieren, der dann faktisch so aussieht, als wären alle Felder in einer Tabelle.

Also, solange das Vorteils-Argument zu vernachlässigen ist, würde ich eine einzige Tabelle nehmen.

Zitat:

Zitat von RWarnecke (Beitrag 1378157)

Die Checkboxen sind reine Multiple-Choice Bereiche. Ich muss nur den Status der Checkbox speichern, sobald er sich ändert und natürlich auch wieder anzeigen, wenn die Maske aufgerufen wird.

30 Checkboxen lassen sich bequem in einem 32-Bit Integer unterbringen - das wäre die platzsparendste Art. Du hast dann nur ein Feld für diese Checkbox-Gruppe. Für den Zugriff bietet sich dann

Delphi-Quellcode:

TIntegerSet

an.

Delphi-Quellcode:

function IsChecked(FieldData, Index: Integer): Boolean;
begin
  Result := Index in TIntegerSet(FieldData);
end;

function SetChecked(FieldData, Index: Integer; Value: Boolean): Integer;
var
  iSet: TIntegerSet;
begin
  iSet := TIntegerSet(FieldData);
  if Value then begin
    Include(iSet, Index);
  end
  else begin
    Exclude(iSet, Index);
  end;
  Result := Integer(iSet);
end;

[jobo]

Das meiste ist schon gesagt.

Was die 30 Checkboxen angeht möchte ich noch zu bedenken geben:
Solange es nicht um Millionen Datensätze geht, ist eine "großzügige" Speicherung mit eigenen Spalten sicher sinnvoll, weil flexibel(er).
1. Was geschieht mit Checkboxen, die zu Tristate oder mehr werden im Laufe des Projekts?
2. Was geschieht mit zusätzlichen Feldern, die am Horizont warten?

30 ja/nein Felder riechen sehr nach dem 31. Feld und so weiter.
Vielleicht nimmt man tatsächlich eine 1:N Relation, wo dann weitere Felder nach belieben aufgenommen werden können, ohne mit Alter Table usw. anzufangen. In die GUI müssen sie natürlich trotzdem irgendwie, dazu hab ich keine Meinung. (Außer dass die DB Struktur dafür relativ egal ist)

[hanvas]

Zitat:

...
30 Checkboxen lassen sich bequem in einem 32-Bit Integer unterbringen - das wäre die platzsparendste Art.

Platzsparend schon, aber nur wenn Auswertungen über SQL gefahren werden sollen unter Umständen ein echtes Problem.

cu Ha-Jö

[Uwe Raabe]

Zitat:

Zitat von hanvas (Beitrag 1378166)

Platzsparend schon, aber nur wenn Auswertungen über SQL gefahren werden sollen unter Umständen ein echtes Problem.

Deswegen hatte ich ja vorher nachgefragt. Erfahrungsgemäß bringt es auch nicht viel, jetzt schon die Probleme von morgen zu lösen - die sind dann wahrscheinlich doch wieder anders. Eine nachträgliche Umstrukturierung der Datenbank auf die dann gültigen Anforderungen ist ja auch nicht verboten.

[p80286]

Zitat:

Zitat von Uwe Raabe (Beitrag 1378156)

In der Regel sollte die visuelle Darstellung nicht als Grundlage für die Datenbankstruktur dienen.

Die beiden haben nichts, aber auch Garnichts miteinander zu tun!

Bei den Kundendaten würde ich nicht sparen.
Wenn die Möglichkeit besteht, daß zu einem Kunden zwei Adresssätze nötig sein könnten, dann auf jeden Fall mit einer KundenMasterTabelle und einer,zwei.. KundendetailTabelle(n) arbeiten.

was die 30 Checkboxen angeht, es kommt darauf an welche Daten sich dahinter verbergen. Es könnte durchaus sein, das 30tabellen, insbesonders im Hinblick auf die Auswertung, hier empfehlenswert sind.

Gruß
K-H

[RWarnecke]

Hallo zusammen,

vielen Dank für die vielen Infos. Ich habe zumindest schonmal eines festgelegt, dass die Daten aus Tab3 in eine extra Tabelle mit einer 1:n Beziehung zur Kundentabelle erstellt werden. Was die bis zu 30 Checkboxen angeht, schwanke ich noch zwischen einem Textfeld (Inhalt : 0;0;1;0;1;1;0;0) mit entsprechender Länge und bis zu 30 Spalten.

[jobo]

Zitat:

Zitat von RWarnecke (Beitrag 1378175)

Was die bis zu 30 Checkboxen angeht, schwanke ich noch zwischen einem Textfeld (Inhalt : 0;0;1;0;1;1;0;0) mit entsprechender Länge und bis zu 30 Spalten.

Wenn Du die Werte in einen String packst oder egal welcher Typ, wenn also in Feld, dann würde ich mir eine sehr gut getestete, absolut wasserdichte Getter/Setter Klasse dazu bauen und jegliche Form von lesendem oder schreibendem Zugriff unterbinden. So, dass die auch für Reporting / Abfragen taugt.
Am besten auch gleich so, dass das fragliche nächste Feld (No 31) ohne großen Aufwand implementierbar (=~anhängbar) ist.

[Uwe Raabe]

Zitat:

Zitat von RWarnecke (Beitrag 1378175)

dass die Daten aus Tab3 in eine extra Tabelle mit einer 1:n Beziehung zur Kundentabelle erstellt werden.

Wieso jetzt 1:n - gibt es denn pro Kundensatz mehrere Tab3-Sätze?

[jobo]

Zitat:

Zitat von Uwe Raabe (Beitrag 1378188)

Wieso jetzt 1:n - gibt es denn pro Kundensatz mehrere Tab3-Sätze?

Ich hatte das so verstanden, dass dort die Felder nicht horizontal, sondern als einzelne Datensätze landen sollen.

[Uwe Raabe]

Zitat:

Zitat von jobo (Beitrag 1378190)

Ich hatte das so verstanden, dass dort die Felder nicht horizontal, sondern als einzelne Datensätze landen sollen.

Das wäre auch nur dann sinnvoll, wenn eben nicht bei jedem Kundensatz entweder alle Tab3 Felder vorhanden sind oder gar keins. Dazu müssten die Datentypen der Tab3-Felder auch alle gleich sein oder zumindest in gleichartigen Gruppen zusammengefasst werden können. Ich hatte das bisher so verstanden, daß eine Eigenschaft des Kundensatzes (in Tab2) entscheidet, ob es Tab3 gibt oder nicht. Dann aber immer alle Tab3-Felder. Wenn dem so ist, wäre eine 1:n Struktur für die Tab3-Daten aber eher kontraproduktiv.

Aber das ist natürlich hier alles nur wilde Spekulation, solange man nichts über die tatsächlich zu speichernden Daten weiß.

[RWarnecke]

Zitat:

Zitat von jobo (Beitrag 1378187)

Wenn Du die Werte in einen String packst oder egal welcher Typ, wenn also in Feld, dann würde ich mir eine sehr gut getestete, absolut wasserdichte Getter/Setter Klasse dazu bauen und jegliche Form von lesendem oder schreibendem Zugriff unterbinden. So, dass die auch für Reporting / Abfragen taugt.
Am besten auch gleich so, dass das fragliche nächste Feld (No 31) ohne großen Aufwand implementierbar (=~anhängbar) ist.

Danke für den Hinweis, aber das habe ich in meiner Überlegung schon mit einbezogen.

Zitat:

Zitat von Uwe Raabe (Beitrag 1378188)

Wieso jetzt 1:n - gibt es denn pro Kundensatz mehrere Tab3-Sätze?

Zu einem Kundendatensatz gibt es entweder Daten aus Tab3 oder nicht. Dieses entscheidet eine Eigenschaft aus Tab2. Die Daten aus Tab3 werden zusätzlich zu einem Kunden aufgenommen oder garnicht.

In allen Tabs sind einzelne Eingabefelder (so wie eine ganz normale Maske aus einer Kundenverwaltung) oder Bereiche als Multiple-Choice Auswahl, das sind dann die Checkboxen.