Hi zusammen

Im Moment bastle ich an einem Testprogramm, mit dem ich die Arbeit mit den im Titel genannten Komponenten austesten möchte. Noch bin ich allerdings auf der Suche nach entsprechenden Forenbeiträgen, die mir meine Fragen (hoffentlich) beantworten können und habe desshalb bislang nur wenig wirklich umgesetzt.
Da ich mit FireDac auf MySQL arbeite, war mein erster Gedanke der an TFDMemtable. Um mir das Prinzip zu verdeutlichen, habe ich trotzdem mal das Tutorial zu MyBase auf Delphi-Treff nachgebaut.
Doch erstmal zur Struktur, wobei es eigentlich egal ist, welche Komponente ich verwende:

markieren

Delphi-Quellcode:

procedure TDMLClientTest.FileQueryLoad;
begin
  FileQuery.FieldDefs.Add('id', ftAutoinc);
  FileQuery.FieldDefs.Add('fk', ftInteger);
  FileQuery.FieldDefs.Add('Name', ftString);
  FileQuery.FieldDefs.Add('Bitmap', ftBlob);
  FileQuery.FieldDefs.Add('NEF', ftBlob);
end;

Der Procedurname ist selbst auch noch nicht in Stein gemeisselt. Passieren soll im Anschluss an obige Zeilen folgendes:

• Die Prozedur iteriert durch eine Pfadliste, die die Dateinamen meiner NEF-Dateien enthält.
• Pro Listitem wird die Nefdatei in eine entsprechende Variable geladen.
• Daraus wird eine Bitmap erstellt.

Nachdem die Pfadliste komplett durchlaufen ist, wird das ganze in eine Datei gespeichert, und gut ist - hoffentlich...
Knackpunkt könnte sein: Die NEF-Dateien sind zwischen 10 und 24 Megabite gross; daraus ertellte Bitmaps sind durchschnitlich dreimal grösser. Das ergibt einen (Arbeits-)Speicherbedarf von knappen 12GB - installiert habe ich deren 8GB...
Ein weiterer Knackpunkt könnte sein, dass das Query gar nicht in der Lage ist, einen Datensatz per SQL in sich selbst zu Speichern...

Auf die Idee, kein TFDMemtable, sondern nur das Query zu verwenden, brachte mich die Erkenntnis, dass TFDMemtable die Möglichkeit, sich selbst in eine Datei zu speichern, von TDataset erbt. Und da das Query dies auch erbt und ich eine Memorytable nicht wirklich brauche - wieso also sollte ich nicht direkt das Query verwenden?

Wie ich oben bereits erwähnt habe, hatte ich mal einen Test mit TClientdataset geschrieben, und von daher stellt sich mir die Frage: wieso nicht gleich das verwenden?
Ein Autoinc-Feld könnte da ein 'Problem' sein.

Was auch immer ich schlussendlich verwende: Es dient dazu,die NEF- und BMP-Bilder nicht in der eigentlichen Datenbank abzulegen, sondern in externen 'Tabellendateien', die auf beliebigen, auch externen Laufwerken, gespeichert werden sollen.

Was würdet ihr verwenden? Was spricht für wen? Was spricht gegen wen?

Gruss
Delbor

Zitat von Delbor:

Knackpunkt könnte sein: Die NEF-Dateien sind zwischen 10 und 24 Megabite gross; daraus ertellte Bitmaps sind durchschnitlich dreimal grösser. Das ergibt einen (Arbeits-)Speicherbedarf von knappen 12GB - installiert habe ich deren 8GB...

Damit fallen eigentlich die In-Memory-DataSets (TClientDataSet, TFDMemTable) aus, da sie den gesamten Datenbestand im Speicher halten.

Hi Uwe Raabe

Zitat:

Damit fallen eigentlich die In-Memory-DataSets (TClientDataSet, TFDMemTable) aus, da sie den gesamten Datenbestand im Speicher halten.

Ich bin mir ja nicht sicher, ob ich das rictig verstanden habe, aber lassen sich nicht mit Fetchoptions.Mode abgerufene Datensätze in Memmoryverträgliche Blöcke gruppieren? Bei TFDQuery ist das Property Fetchoptions mal bestimmt dabei.

Gruss
Delbor

Zitat von Delbor:

Ich bin mir ja nicht sicher, ob ich das rictig verstanden habe, aber lassen sich nicht mit Fetchoptions.Mode abgerufene Datensätze in Memmoryverträgliche Blöcke gruppieren? Bei TFDQuery ist das Property Fetchoptions mal bestimmt dabei.

TFDQuery holt sich die Daten ja aus bzw. speichert sie in einer externen Datenbank. Das ist wegen der beschriebenen Datengröße auch wohl nicht anders zu machen. Die beiden In-Memory-Datasets halten dagegen den gesamten Datenbestand im Hauptspeicher. Wenn du bis zu 12 GB Daten erwartest, benötigst du mindestens 16 GB Hauptspeicher (das PageFile können wir hier getrost vernachlässigen) und musst eine 64-Bit Anwendung draus machen. Ob damit dann allerdings ein sinnvolles Arbeiten mit den Datensätzen möglich ist, erscheint eher zweifelhaft.

Hi Uwe Raabe

Zitat:

TFDQuery holt sich die Daten ja aus bzw. speichert sie in einer externen Datenbank.

Das sehe ich jetzt auch als Antwort auf die Frage, die ich mir selbst stelle:

Zitat:

Ein weiterer Knackpunkt könnte sein, dass das Query gar nicht in der Lage ist, einen Datensatz per SQL in sich selbst zu Speichern...

So, wie ich das bis jetzt sehe, fallen also schlichtweg alle drei genannten Komponenten zumindest fürdas angedachte Vorgehen aus.

Zitat:

Wenn du bis zu 12 GB Daten erwartest, benötigst du mindestens 16 GB Hauptspeicher (das PageFile können wir hier getrost vernachlässigen) und musst eine 64-Bit Anwendung draus machen. Ob damit dann allerdings ein sinnvolles Arbeiten mit den Datensätzen möglich ist, erscheint eher zweifelhaft.

Das heisst eigentlich nichts anderes, als an der vorgesehnen Stelle eine eigene DB zu erstellen, die dann, ob ich mir das nun vorstellen kann oder nicht, eine einzige Tabelle mit den eingangs erwähnten Strukturen enthält. Auf diese liesse sich dann ein Insert-Statement absetzen, dass gerade mal einen einzigen Datensatz einfügt.

Gruss
Delbor

Warum willst Du dann NEF und Bitmap in der DB speichern?
Bitmap soll ja wohl kein thmubnail werden, oder?

Wenn Du NEFs in Bitmaps konvertieren kannst, greife auf die NEFs zu und konvertiere on the fly beim Zugriff. Damit sparst Du unheimlich Platz - egal ob im Arbeitsspeicher oder auf der Platte.

Zitat von Delbor:

Das heisst eigentlich nichts anderes, als an der vorgesehnen Stelle eine eigene DB zu erstellen, die dann, ob ich mir das nun vorstellen kann oder nicht, eine einzige Tabelle mit den eingangs erwähnten Strukturen enthält. Auf diese liesse sich dann ein Insert-Statement absetzen, dass gerade mal einen einzigen Datensatz einfügt.

Genau! Dabei kannst du natürlich auch eine Embedded Datenbank wie z.B. SQLite, Firebird Embedded oder MSSQL LocalDB nehmen. Dann musst du nicht erst einen eigenen Datenbankserver aufsetzen (wobei das in der Regel auch nicht schwierig ist). Als Zugriffskomponente kannst du ja bei TFDQuery bleiben.

Hi bnreimer42

Zitat:

Bitmap soll ja wohl kein thmubnail werden, oder?

Aus dem NEF gibt es beim Einlesen zwei TBimaps. Beide werden aus dem NEF erstellt, wobei die eine ohne Grössenveränderung in der DB gespeichert wird. Die zweite wird zum Thumbnail verkleinert, in Jpeg konvertiert und anschliessend verworfen.

Zitat:

Wenn Du NEFs in Bitmaps konvertieren kannst, greife auf die NEFs zu und konvertiere on the fly beim Zugriff. Damit sparst Du unheimlich Platz - egal ob im Arbeitsspeicher oder auf der Platte.

Zitat:

Warum willst Du dann NEF und Bitmap in der DB speichern?

Die Aufgabenstellung heisst:

• Die Rohdaten müssen jederzeit wieder abrufbar sein. Die Nefs müssen also erhalten bleiben. Da ich sie aber eben nicht in meiner (Haupt-) Datenbank speichern will, sollen sie ja eben ausgelagert werden.
• Diei Bitmaps dienen zur weiteren Bearbeitung der Bilder und müssen desshalb auch erhalten bleiben. Ansonsten gilt dassselbe wie für Rohdaten.

Gruss
Delbor

Hi Uwe Raabe

Zitat:

Genau! Dabei kannst du natürlich auch eine Embedded Datenbank wie z.B. SQLite, Firebird Embedded oder MSSQL LocalDB nehmen. Dann musst du nicht erst einen eigenen Datenbankserver aufsetzen (wobei das in der Regel auch nicht schwierig ist). Als Zugriffskomponente kannst du ja bei TFDQuery bleiben.

Einen eigenen Server brauch ich da wirklich nicht - es würde reichen, mit MySQL Workbench so eine Ein-Tabellen-DB zu entwerfen, das Modell mit einer"DB" (Ordner für die DB) zu verbinden und die DB per Forward Engineering erstellen zu lassen.
Da ich aber sowieso vorhabe, die für die Anwendung massgebliche Datenbank auf SQLite umzustellen, bietet es sich hier geradezu an, dieses auch hier zum Einsatz kommen zu lassen.

Gruss
Delbor

Sqlite wäre auch ein Kandidat für mich.
Die Frage die ich mir stelle ist ob die nicht auch alles im memory hält. Oder zumindest nur den aktuellen Datensatz. Kann man das paging steuern ?