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 von RWarnecke:

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 von Uwe Raabe:

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 von Uwe Raabe:

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 von RWarnecke:

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 von RWarnecke:

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 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 von hanvas:

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 von Uwe Raabe:

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.