Zitat von
Cogito:
Der gravierendere Nachteil ist, dass alle Felder (also in deinem Falle die abhängige Fondsproperty-Tabelle) in einem EndUser-Reportdesigner zur Verfügung stehen müssen, um sie in selbstdefinierbaren Reports verwenden zu können. Diese Reports sind strukturierte Templates, keine einfachen Listen. In deinem Beispiel handelt es sich aber gar nicht um Felder, sondern um Datensätze. Wie könnte also ein Endbenutzer bei diesem
DB-Aufbau einen Report aufbauen, er hätte ja lediglich ein Key-Value Pärchen.
Das Problem ist generell bei mir, das der Endbenutzer sehr viel selbst machen möchte, sowohl Import definieren, Reports bauen sowie frei definierbare Ausgaben für Excel gestalten, um diese dort eventuell weiterzubearbeiten.
Beides ist eigentlich kein Wiederspruch. Wenn zum Beispiel für einen Reportdesigner die Felder bereitgestellt werden sollen, baut man einfach eine passende Abfrage zusammen.
Code:
select a.id, a.name,
b.PropertyValue Property1,
c.PropertyValue Property2
/* usw. */
from Fond a
left join FondProperty b on (b.FontId = a.id) and (b.PropertyName = 'Property1')
left join FondProperty c on (c.FontId = a.id) and (c.PropertyName = 'Property2')
/* usw. */
So ein
SQL kann leicht maschinell erzeugt werden, wenn sich der Anwender die gewünschten Properties zusammenklicken will.
Ähnliches trifft auf Update- oder Inserts beim Import zu.