"Gemischte Daten" abspeichern

[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 ...

[sko1]

Ihr seid ja klasse!

Langsam kann ich mich mit der SQLite-Version auch anfreunden, Ziel (oder besser Vorgabe) ist es eben eine Datei pro "Sammelsurium" zu bekommen.

Jetzt schwanke ich nun zwischen 3 verschiedenen Lösungsansätzen...

Ciao
Stefan

[nahpets]

Eine Datenbank ist letztlich ein Sammelsorium von Daten.

Eine Datenbank für Tipps rund um Delphi.
Eine Datenbank für Tipps rund um Datenbanken.
Eine Datenbank für Rezepte.
Eine Datenbank für Reisebeschreibungen.

Wenn alle die gleiche Struktur haben, kannst Du durch (dialoggesteuerten Wechsel) der Datenbank aus einer Tippverwaltung eine Rezepteverwaltung machen.

Daternbanken sind nicht zwingend was ominös überdimmensioniertes, das auch Daten enthält.

Sie sind ggfls. auch einfach nur ein kleiner Container für eine überschaubare Datenmenge.

Sinn ist letztlich die strukturierte Ablage von Daten zwecks einfacher Verwaltung von zusammengehörigem.

Und wenn eine Datenbank nur eine Tabelle enthält? Dann ist das halt so.

Und das schön daran ist:

Wenn in jedem Datensatz der Typ steht, kannst Du über die Abfrage des Typs in einer If-Kaskade oder per Case, sehr einfach die Inhalte der Blobspalte auslesen.

Sinngemäß ungefähr sowas:

Delphi-Quellcode:

Case Datensatz.FieldByName('Type').AsInteger of  // oder ein Aufzählungstyp?!?
  1: IntegerVariabel := Datensatz.FieldByName('Blob').AsInteger;
  2: StringVariabel := Datensatz.FieldByName('Blob').AsString;
  3: Memo.Add(Datensatz.FieldByName('Blob').AsString);
  4: ImageLaden('http://www.delphipraxis.net/117340-blob-per-stream-aus-db-lesen-und-imageview-anzeigen.html');
else
  ShowMessage('Upps, unbekannter Typ.');
end;

[hhcm]

Da mag jetzt jeder seine Vorlieben haben.
Gerade die Unterschiedlichen Datentypen schreien geradezu nach einer Datenbank.
Alleine der Vorteil die Daten auch direkt Visualisieren zu können (fast ohne eine Codezeile)

[nahpets]

Habe mir mal eine Textverwaltung geschrieben.

Mehrere Datenbanken (unterschiedlichster Typen (MSSql, Oracle, PostGres, FireBird, Access)) können per Dialog ausgewählt werden.

Jede Datenbank hat eine (wesentliche) Datentabelle.
Die Struktur ist immer gleich.

Enthalten sind Rezepte, Romane (zur EPub-Erstellung), diverser Informationssammlungen ...

Alle können einheitlich mit einem Programm "verarbeitet" werden.

Neu Sammlung?

Neue Datenbank, Tabelle anlegen, dafür sorgen, dass die Datenbank ausgewählt werden kann und schon sind alle Funktionalitäten verfügbar.

Als kleinsten Nenner für die "Datenbankunabhängigkeit" hab' ich mich für die ADO-Komponenten entschieden.

Die Datenbanken kann man daher über den Connctiondialog von TADOConnection auswählen. Ggfls. muss man vorher 'nen ODBC-Treiber einrichten.

Da es sich hier nicht um Hochleistungssysteme handelt, halt' ich diese schon etwas antiquierte Technik für durchaus ausreichend.


Macht man sowas neu und nutzt SQLite, wählt man über 'nen Dialog die passende Datenbankdatei aus und hat mit sehr wenig Aufwand recht schnell eine Software, mit der man "grenzenlose" Mengen von unterschiedlichsten Daten verwalten kann, ohne sie miteinander vermischen zu müssen.