max. Anzahl Felder erreicht - was nun?

[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

[Cogito]

Zitat:

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.

[mkinzler]

Mit mehr Wissen, über die Struktur der Tabelle könnte man dir u.U. gezielter helfen.
BTW. Access schient wirklich di falsche Lösung zu sein

[Cogito]

Zitat:

Zitat von mkinzler

Mit mehr Wissen, über die Struktur der Tabelle könnte man dir u.U. gezielter helfen.
BTW. Access schient wirklich di falsche Lösung zu sein

Da geb ich dir zweifelsfrei recht, nur hab ich leider keine andere Wahl :cry:

[hoika]

Hallo,

keine Wahl bei Access als Entwicklungsumgebung oder Datenbank ?

Für Access gibt es z.B. "Access Project" zum Zugriff auf MS-SQL.
Die ganzen Assistenten, kurz das ganze "Access" funktioniert weiter.

Frag mich nicht, wieso das "Project" heisst.


Heiko

[p80286]

Hallo zusammen,

also auf zur nächsten Prügelei (ACCESS ist pfui ba)

Aber davon einmal abgesehen
1) wenn der Kunde unbedingt auf ACCESS besteht, könnte dies durchaus Gründe haben. Z.B. müßte für eine "richtige" DB erst ein Server beantragt und dann eingerichtet werden. Ggf. muß die notwendige Software dann noch durch irgendwelche Tests geschleust werden. Das alles entfällt wenn ACCESS eh schon vorhanden ist. Und Kosten sind ein wesentlich stichhaltigeres Argument als irgendwelche obskuren techn. Features.
2) ACCESS als Client für DB-Zugriffe ist eigentlich nur dann einsetzbar wenn man weiß welche Schwächen ACCESS hat. Für den Kunden sieht's so aus als wäre es eine ACCESS-DB, aber warum diese Mimikry? Dafür gibt es doch schließlich das in Delphi geschriebene Programm, das alles zur Verfügung stellt, was der Kunde als DB-Schnittstelle benötigt.

Gruß
K-H

[Blup]

Zitat:

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.

[quendolineDD]

Zitat:

bei diesem DB-Aufbau einen Report aufbauen, er hätte ja lediglich ein Key-Value Pärchen.

Gerade dabei geht es ja in der Datenbanknormalisierung. Somit sind alle Datensätze transitiv von den Schlüsselmerkmalen abhängig.
Deswegen gibt es ja auch solch wunderbare Sachen wie inner join, left join, right join, outer join ... Ich persönlich nehm für lokale Zwecke meist SQLite.