Zitat von
hoika:
Hallo,
für unendliche viele Fonddaten reichen erst mal 2 Tabellen
Tabelle 1,
Fond
Id Integer prim key
Name Char(xxx) Fondname
Tabelle 2,
FondProperty
Id Integer prim key
FondId Integer Referenz auf Fond.Id
PropertyName Char(X)
sPropertyValue Char(X)
Das
sPropertyValue ist übrigends Absicht.
Wem es nämlich nicht gefällt, z.B. Integer als String zu speichern,
fügt noch ein Feld
iPropertyValue Integer dazu.
Das "Zusammsammeln aller Properites wird mit einer
Query erledigt
Select * From FondProperty
Where FondId=XXX
Der einzige Nachteil ist,
dass bei Verwendung mehrerer FondValue felder das ganze nicht so einfach in einem
DBGrid angezeigt werden kann.
Das ich persönlich das eh nicht benutze ...
Mit einer richtigen
DB geht das aber doch über
if im Select-Statment.
Heiko
Diese Lösung hatte ich mir am Anfang auch schon mal überlegt, sie hat aber für meinen Fall 1 schweren Nachteil (davon abgesehen das eine Datenpflege oder gar Import hierbei sehr aufwändig wäre, weil man nicht auf Feldebene die Ausgangsdatenmenge mit der Zieldatenmenge matchen könnte):
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.