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
