Wie Datenbankstruktur aufbauen ?

[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.

[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.