AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken Delphi max. Anzahl Felder erreicht - was nun?
Thema durchsuchen
Ansicht
Themen-Optionen

max. Anzahl Felder erreicht - was nun?

Ein Thema von Cogito · begonnen am 2. Apr 2009 · letzter Beitrag vom 7. Apr 2009
Antwort Antwort
Seite 5 von 5   « Erste     345   
hoika

Registriert seit: 5. Jul 2006
Ort: Magdeburg
8.276 Beiträge
 
Delphi 10.4 Sydney
 
#41

Re: max. Anzahl Felder erreicht - was nun?

  Alt 5. Apr 2009, 11:43
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
Heiko
  Mit Zitat antworten Zitat
Cogito

Registriert seit: 12. Jun 2008
280 Beiträge
 
#42

Re: max. Anzahl Felder erreicht - was nun?

  Alt 5. Apr 2009, 13:57
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.
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
39.861 Beiträge
 
Delphi 11 Alexandria
 
#43

Re: max. Anzahl Felder erreicht - was nun?

  Alt 5. Apr 2009, 15:32
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
Markus Kinzler
  Mit Zitat antworten Zitat
Cogito

Registriert seit: 12. Jun 2008
280 Beiträge
 
#44

Re: max. Anzahl Felder erreicht - was nun?

  Alt 5. Apr 2009, 17:25
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
  Mit Zitat antworten Zitat
hoika

Registriert seit: 5. Jul 2006
Ort: Magdeburg
8.276 Beiträge
 
Delphi 10.4 Sydney
 
#45

Re: max. Anzahl Felder erreicht - was nun?

  Alt 6. Apr 2009, 09:05
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
Heiko
  Mit Zitat antworten Zitat
Benutzerbild von p80286
p80286

Registriert seit: 28. Apr 2008
Ort: Stolberg (Rhl)
6.659 Beiträge
 
FreePascal / Lazarus
 
#46

Re: max. Anzahl Felder erreicht - was nun?

  Alt 6. Apr 2009, 10:43
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
  Mit Zitat antworten Zitat
Blup

Registriert seit: 7. Aug 2008
Ort: Brandenburg
1.477 Beiträge
 
Delphi 12 Athens
 
#47

Re: max. Anzahl Felder erreicht - was nun?

  Alt 7. Apr 2009, 15:58
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.
  Mit Zitat antworten Zitat
quendolineDD

Registriert seit: 19. Apr 2007
Ort: Dresden
781 Beiträge
 
Turbo Delphi für Win32
 
#48

Re: max. Anzahl Felder erreicht - was nun?

  Alt 7. Apr 2009, 16:05
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.
Lars S.
Wer nicht mit der Zeit geht, geht mit der Zeit.
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 5 von 5   « Erste     345   


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 00:21 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz