Mehrschichtige Datenstruktur ohne Datenbank

[xnickels]

Hallo, liebe DPler.

Für eine Anwendung benötige ich einen Denkanstoß, um eine Datenstruktur aufzubauen, für die ich keine Datenbank verwenden kann.

Am besten schildere ich mal meinen Ansatz, wie ich dieses Problem mit einer Datenbank lösen würde.

Ich benötige drei Tabellen:

1. Modellnamen
2. Herstellern
3. Dateinamen

Zu den Modellnamen speichere ich den Hersteller und den Dateinamen ab. In der Windows-Form wähle ich den Hersteller in einer Combo-Box oder in einem DBGrid aus. Nach dem Auswählen stehen mir alle Modelle zu diesem Hersteller in einer weiteren Combo-Box zur Verfügung. Zur späteren Weiterverarbeitung benötige ich jetzt noch die Angabe des Dateinamens zu diesem Modell.

Ist es sinnvoll, diese "Tabellen" in Stringlisten zu packen und im Modellnamen als weitere Information (z. B. durch ein | getrennt) den Indexwert des jeweiligen Herstellers / Dateinamens anzuhängen? Dann würde ich beim Befüllen der Combo-Box diese Informationen wieder abschneiden, damit diese nicht zu sehen sind.

Oder gibt es noch "schönere" Lösungen?

Ein TreeView möchte ich an dieser Stelle nicht verwenden, die Lösung mit Combo-Boxen wäre für mich eigentlich optimal, da die weiteren Funktionen der geplanten Anwendung deren Einsatz am besten unterstützen.

Vielen Dank schonmal für Eure Hilfe.

[RWarnecke]

Hallo und herzlich Willkommen in der DP :dp:

als erstes würde mir da spontan XML einfallen um die Daten zu speichern.

Edit: Link hinzugefügt.

[nahpets]

Hallo,

wie wäre es mit DBasetabellen, aber ohne BDE. Da gibt es die Komponente TDBF, die ich ganz gerne für ähnliche, kleinere Sachen benutze. Man kann damit alles benutzen, was man für eine "normale" Datenbankapplikation auch benutzt (DBGrid, DBNavigator...).
Ansonsten käme noch kbmMemTable in Frage, das ist eine Datenbanktabelle, die nur im Arbeitsspeicher vorgehalten wird, mit der Möglichkeit, die Daten (nach Gebrauch) in eine Datei zu schreiben und auch wieder aus der Datei zu lesen. Auch hier gilt: Benutzung erfolgt wie jede andere Datenbank auch.
Mit beiden Varianten hat man nur marginal zusätzlichem Aufwand, im Vergleich zu "üblichen" Datenbankanwendungen.

[xnickels]

Hallo und vielen Dank.

Ich habe mittlerweile die Komponente TClientdataset entdeckt und werde diese einmal ausprobieren. Oder gibt es Gründe, die hiergegen sprechen?

Sönke

[mjustin]

Zitat:

Zitat von xnickels

Hallo und vielen Dank.

Ich habe mittlerweile die Komponente TClientdataset entdeckt und werde diese einmal ausprobieren. Oder gibt es Gründe, die hiergegen sprechen?

Sönke

Solange man unter einigen zehntausend Sätzen bleibt, eigentlich nicht. Vor allem die Möglichkeit, die Daten z.B. als XML Datei abzuspeichern, ist reizvoll, und natürlich bestehen alle Möglichkeiten der Master/Detail-Verknüpfungen, und der einfachen Erkennung welche Felder sich beim Speichern des Satzes über Post änderten. (Oldvalue/Newvalue). ClientDataSet ist bei der DB-Entwicklung schon fast so etwas wie ein Schweizer Taschenmesser ...