Na klar 1:n, was sonst?
Wieso weniger Flexibilität?
Wenn Du deine 3NF verwendest, fügst Du eine neue 'Spalte' so ein:
Code:
insert into Details (CustomerID,FlagID) values (12345,'X')
Wenn du alle Spalten in einer Tabelle hast, dann so (allerdings für alle Kunden):
Code:
ALTER TABLE Customer ADD 'FlagX' bit not null (0)
Entfernen analog. Wo ist da jetzt die fehlende Flexibilität?
Wie gesagt: Ich habe es genau so gemacht. Es ist *viel* einfacher so.
Das ist natürlich kein Plädoyer gegen Normalisierung, nur 'um jeden Preis' eben nicht.
Eine
SQL-Datenbank mit 40000 Datensätzen, die jeweils ca. 150-200 Properties besitzen (unterschiedliche Produkte in einer Tabelle) und als
EAVund modelliert war, ist performancetechnisch ziemlich in den Keller gegangen.
Gerade wenn es sehr viele optionale Daten werden, würde ich aufpassen und lieber den denormalisierten Ansatz nehmen. Oder -was eigentlich optimal wäre- die optionalen Felder gruppieren und die Gruppe dann als eigene Tabelle modellieren.