Wie Datenbankstruktur aufbauen ?

[RWarnecke]

Zitat von jobo:

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

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.

[Uwe Raabe]

Zitat von RWarnecke:

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

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.

[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