TClientdataset vs. TFDMemTable vs. TFDQuery

[Delbor]

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

[bnreimer42]

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.

[Delbor]

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

[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

[Rollo62]

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 ?

[Uwe Raabe]

Zitat von Rollo62:

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.

Die (theoretisch) maximale Datenbankgröße für SQLite ist ca. 140 Terabyte - das sollte deine Frage beantworten.

[DeddyH]

Da musst Du aber große RAM-Riegel in den Rechner stecken

[hanvas]

Zitat von Delbor:

Hi bnreimer42

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.

und...

Zitat:

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.

Mir ist immer noch nicht klar warum die Bilddaten unbedingt in der DB gespeichert werden müssen. Wäre es kein gangbarer Weg die Bitmaps und NEFs gar nicht als Blob sondern als File oder sonstwie extern abzulegen und in der Datenbank lediglich einen Zugriffspfad und ggf. notwendige Metadaten zu speichern. Das die Daten jederzeit abrufbar sein müssen ist dafür doch kein Hindernis. Wenn nötig kannst Du die Bilddaten doch genauso gut aus dem File laden auf die der Datensatz in der DB zeigt, komplizierer als die Daten aus einem Blob zu laden ist das auch nicht wirklich.

Wenn Du eine "Vorschau" brauchst kannst Du ja das bisher verworfene Thumbnail zusätzlich in der DB speichern.

cu Ha-Jö

[Uwe Raabe]

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.