Wie Datenbankstruktur aufbauen ?

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