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