"Gemischte Daten" abspeichern

[sko1]

Hallo,

irgendwie stehe ich auf dem Schlauch:

Ich muss ein Wirrwarr an verschiedensten Informationen in eine Datei speichern Zahlen, Strings, Bilder (liegen als Stream vor) usw.

Den Ansatz, XML zu verwenden und die Streams umzukonvertieren, habe ich verworfen (bläst die Bilder auf).

Hat jemand bitte einen Denkanstoß für mich?

Ciao
Stefan

[TiGü]

Wie wäre es mit BSON?
http://docwiki.embarcadero.com/RADStudio/Berlin/de/BSON

[TiGü]

Oder die Streams vorher komprimieren?
http://www.swissdelphicenter.com/de/showcode.php?id=822
https://stackoverflow.com/questions/...ess-decompress

[nahpets]

'ne Datenbank (Access, Embedded FireBird ...)

Und darin eine Tabelle in der Form:

1. ID - AutoInc - als technischer Schlüssel
2. Beschreibung - String/Varchar(100) - verbale Beschreibung
3. Type - Integer - zur Typunterscheidung des folgenden Inhalts, eventuell ein Aufzählungstyp.
4. Wert - Blob - der Inhalt der Information

Damit könntest Du dann in der Blobspalte beliebige Inhalte ablegen, über den Typ wird entschieden, wie der Inhalt auszulesen ist.

Damit können Texte, Bilder, Zahlen, Dateien ... in einer Tabelle abgelegt werden, ohne dass für jeden "Sonderfall" eine besondere Tabelle oder sonstige Ablageform erforderlich wird.

Eine komprimierte Ablage im Blob wäre für Dateien, Texte, Bilder ... zusätzlich möglich.

[sko1]

Vielen Dank für die schnelle Hilfe!

BSON klingt nach erstem Anschauen sehe sehr interessant!
Da werde ich mal weiter forschen, Datenbank scheidet aus, es sollen "Einzeldateien" entstehen

Die Streams komprimieren wäre auch ein Ansatz, dann könnte ich ja aber gleich die fertige Datei als Ganzes komprimieren...

Ich habe jetzt erst mal genügend Ansätze zum Testen

[himitsu]

Es gibt auch von XML eine komprimierte "binäre" Version.

Und unkomprimiert, als Base64, sind Binärdaten auch nur 33% größer. (ohne Komprimierung lässt sich sowas auch locker auf annähernd 15% bekommen, wenn man mehr als 64 der ersten 128 Zeichen verwendet)
Also eigentlich fällt es kaum auf, bei den Exabyte, die wir sonst so rumliegen haben.

[hhcm]

Access oder SQLite wären Einzeldateien. Gibts noch andere gründe keine DB zu verwenden ?

[nahpets]

Unter Einzeldatei würd' ich in dem Zusammenhang verstehen:

eine Information -> eine Datei

Man müsste etwas genauer wissen, was für Informationen zu welchem Zweck hier verwaltet werden sollen, dann kann man sinnvoll über Alternative Speichermöglichkeiten nachdenken.

So ist's etwas dürftig.

Gegen eine Datenbank spricht nur:

Man müsste ggfls. das konzeptionelle Vorgehen der bisherigen Lösungsansätze überdenken

[mensch72]

mein Ansatz für "mehrere Infos pro Datensatz" gleich "eine Datei":

Ich verwende da eine normale Archivdatei als Container (meist 7z oder zip)... da sind alle Streams und Infos als Dateien drin, und künnen sogar mit Standardprogrammen geöffnet werden. Das geht mit benannten ".txt",".csv"...".xyz" Streams auch völlig im RAM ohne zusätzliche "TempFiles".

[nahpets]

Bedeutet kurz und knapp:

Aus meinem Ansatz mit Datenbank und Datensatz wird aus jedem Datensatz eine Datei. Der "Rest" kann letztlich in ähnlichem Zusammenhang in jeder Datei (= jedem Container) abgelegt werden.

Ist auch eine Möglichkeit.

Jede Datei enthält dann z. B. eine Textdatei mit den Infos aus Beschreibung und Type und zusätzlich die gepackte eigentliche Information.

Das kann man insgesamt im Programm dann fast wie eine Datenbank händeln.

Passende Klasse bauen und es wird für den Anwender recht transparent, kann in 'nem Tree, ListView, Stringgrid ... übersichtlich angezeigt und verwaltet werden ...