Datenbanken auf externe Platten auslagern?

[Delbor]

Hi zusammen

Was spricht dagegen, eine Datenbank (zB. SQLite) auf einem externen Laufwerk anzulegen?

Wer meine Threads etwas verfolgt hat, weiss, dass ich für meine Bilderdatenbank aktuell MySQL verwende. Doch schon seit geraumer Zeit liebäugele ich damit, dafür SQLite einzusetzen, da meine Anwendung grundsätzlich keine Multiuserfähige DB benötigt.

Da die Anwendung Daten für eine Webseite erstellen soll, ist es erstmal egal, mit welchem DBMS sie das tut, weshalb sich meines Erachtens SQLite geradezu aufdrängt.

Nach Erstellung der Daten sollen diese allerdings zu einer Webserveranwendung, welche dann unter MySQL läuft, exportiert werden. Wie ich das bewerkstellige, weiss ich zur Zeit noch nicht detailliert, aber ich denke da schonmal an Datasnap; wie auch immer: das ist hier nicht Teil meiner Frage.

Die ist viel mehr:
Aufgrund des jetztigen DB-Modells soll unter SQLite mindestens eine neuue Datenbank erstellt werden.
Die jetzige DB umfasst

• Felder für NEF-Dateien (Rohdatenformat aus der Kamera), Grösse aktuell 10 -24 MB.
• Felder für BMP-Dateien ("Bearbeitungsformat"), im Schnitt gut 3mal so gross, wie die NEF-Bilder, und zu guter letzt:
• Felderfür Jpegs. Deren Grösse ist letztlich Webseitenverträglich(Grösste Seitenlänge etwa 1200px).
• Dazu kommen künftig noch Felder für Videodateien.

Meine Sammlung umfasst zur Zeit gute 13'000 Bilder im NEF-Format und wird natürlich weiter anwachsen.Zusammen mit bereits "von Hand" erstellten Bitmaps und Jpegs sowie einigen Videos füllen die Dinger mittlerweile eine 1-Terabyte-Disk. Grund genug, anzunehmen, dass die 2TB meiner DB-Disk (Intern) nicht allzulange vorhalten werden...

Die Lösung sehe ich darin, für die verschiedenen benötigten Formate jeweils eine eigene DB zu erstellen, und jede dieser separaten DB's muss sich auf einem beliebigen, auch externen, Laufwerk befinden.
Da aber gerade MySQL voraussetz, dass sich alle seine Daten im selben Verzeichnis befinden (es gibt, zumindest in der Community-Version nur ein DataDir), bin ich nicht sicher, ob mein Vorhaben (mehrere DBs auf verschiedenen externen Laufwerken) so ohne weiteres umsetzbar ist.

Ich hoffe, die Zielsetzung genügend gut beschrieben zu haben und freue mich auf eure Kommentare!

Gruss
Delbor

[bra]

SQLite ist nicht gut geeignet, große Dateninhalte zu speichern, die Performance geht dann massiv in die Knie. Zumindest war das vor einigen Jahren noch so der Fall. Also falls du die Bilder IN der Datenbank speicher willst, ist SQLite wohl keine so gute Wahl.

https://sqlite.org/intern-v-extern-blob.html

[HolgerX]

Hmm..

Zitat:

Zitat von Delbor (Beitrag 1366660)

• Felder für NEF-Dateien (Rohdatenformat aus der Kamera), Grösse aktuell 10 -24 MB.
• Felder für BMP-Dateien ("Bearbeitungsformat"), im Schnitt gut 3mal so gross, wie die NEF-Bilder, und zu guter letzt:
• Felderfür Jpegs. Deren Grösse ist letztlich Webseitenverträglich(Grösste Seitenlänge etwa 1200px).
• Dazu kommen künftig noch Felder für Videodateien.

Meine Sammlung umfasst zur Zeit gute 13'000 Bilder im NEF-Format und

Puh..
Das sind Datenmengen..

Da dein Programm eigentlich wie ein DMS funktioniert und mit kein DMS bekannt ist, welches so große Dateien in seine DB speichert, solltest Du Dir vielleicht überlegen die Dateien nicht mehr in die DB zu packen, sondern extern und nur eine Verlinkung mit Tags und Co in der DB zu speichern.

Dann kannst Du auch SQLite verwenden.. ;)

Zusätzlich würdest Du auch dann noch an die Bilder kommen, wenn sich dein Datenbank-File auf der Externen HD aufgrund einer Engergie-Sparoption verabschiedet ;)

[Bernhard Geyer]

Zitat:

Zitat von bra (Beitrag 1366664)

SQLite ist nicht gut geeignet, große Dateninhalte zu speichern, die Performance geht dann massiv in die Knie.

Kann ich bestätigen.
Als wir eine alternative zu ADS Local Server gesucht hatten wurde auch SQLite getestet.
Keine Fehler gefunden was SQL-Abfragen betrifft, aber die Performance war unter alle Kanone.

[Jumpy]

Weiterhin spricht dagegen, das dies ein unausagekräftiger Thread-Titel ist.


Edit: Damit ich nicht nur mecker: Bei dem was du dann in die DB packen willst, wäre vllt. eine NoSQL Datenbank mal ein ganz anderer Ansatz?

[Ghostwalker]

Solange SQLite lokal als Singleuser läuft, gehts auch bei mir mit der Performance (ok..hab nur einige 100 GB Daten).

Da das ganze ins Web soll, würd ich, wie Jumpy schon hingewiesen hat, auf eine NoSQL-Datebank setzten (evtl. mit Elastic Search als Engine). Das kommt recht sicher mit sehr großen Datenmengen klar und bietet den Vorteil skalibar zu sein (Build in).

D.h. sollte in DB-Server nicht mehr ausreichen, hängst du einfach einen zweiten rein und das System kümmert sich darum, woher der Datensatz kommt.

[Daniel]

Ich habe den Titel mal angepasst.

[p80286]

Zitat:

Was spricht dagegen, eine Datenbank (zB. SQLite) auf einem externen Laufwerk anzulegen?

Nichts solange Du das lokal machst. Sobald die Daten Teil eines Ganzen sind mußt Du in diesem System mindestens die Abfrage haben od die Daten vorhanden sind und falls Nein wie das System damit umgehen soll. Ich halte ein USB-Laufwerk als Datenspeicher in diesem Zusammenhang für eine Bastellösung, über ein HotswapLW kann man vllt. diskutieren, aber wenn Du wirklich eine Webseite füttern willst, dann sollten Deine Stichworte Raid und ggf. SSD lauten.
Ichg habe vor vielen Jahren eine Abteilungsdatenbank mit externen (SCSI)Laufwerken betrieben, das willst Du Dir nicht ernsthaft antun.

Gruß
K-H

[jobo]

Zitat:

Zitat von Delbor (Beitrag 1366660)

Was spricht dagegen, eine Datenbank (zB. SQLite) auf einem externen Laufwerk anzulegen?

Wer meine Threads etwas verfolgt hat, weiss, dass ich für meine Bilderdatenbank aktuell MySQL verwende. Doch schon seit geraumer Zeit liebäugele ich damit, dafür SQLite einzusetzen, da meine Anwendung grundsätzlich keine Multiuserfähige DB benötigt.

Die Lösung sehe ich darin, für die verschiedenen benötigten Formate jeweils eine eigene DB zu erstellen, und jede dieser separaten DB's muss sich auf einem beliebigen, auch externen, Laufwerk befinden.
Da aber gerade MySQL voraussetz, dass sich alle seine Daten im selben Verzeichnis befinden (es gibt, zumindest in der Community-Version nur ein DataDir), bin ich nicht sicher, ob mein Vorhaben (mehrere DBs auf verschiedenen externen Laufwerken) so ohne weiteres umsetzbar ist.

Also bei SQLite spricht nichts gegen ein externes Laufwerk. Außer dass man die mal versehentlich abklemmt und das auch eine SQLite DB vielleicht nicht überlebt (ähnlich wie ein FileCopy in einer laufenden mySQL Instance schwerlich funktioniert)
Erinnere ich mich richtig, dass Du mit der mySQL DB "Schwierigkeiten" hattest, nachdem Du Dateien im laufenden Betrieb kopiert hast?

Falls ja oder auch falls ich mich vertue:
Ich krieg bei solchen Fragen leichtes Magenzwicken. (Der Thread mit der defekten mySQL DB steckt mir wahrscheinlich noch irgendwo quer)

Ich kann verstehen, wenn Du mit SQLite Komplexität abbauen willst gegenüber mySQL. Aber ich habe Zweifel, ob Du da richtig dran gehst.

zuerst: Auch wenn SQLite nur noch eine Datei ist, sowas gehört allenfalls als Backup oder vielleicht in Form eines Netzlaufwerks nicht auf eine lokale Platte.
Wie DB auf Verbindungsabbrüche, Schreibstörungen, .. reagieren kann man in dem erwähnten Thread nachlesen. Das gilt auch für DB, die nur aus einer Datei bestehen.
Dass Du fehlende Multiuserzugriffe anführst, zeigt ja, dass Du Dir Gedanken gemacht hast, aber wenn es um meine eigenen Daten geht und davon noch Terrabyte, würde ich mir recht viele Gedanken machen.

zweitens: gleichförmige Daten in verschiedene Tabellen oder sogar Datenbanken zu speichern ist möglich, aber erhöht den Programmier / Adminaufwand unnötig. Es muss halt alles 2x, 3x, 5x gemacht werden und im Zweifel muss es sogar noch konsistent sein.

drittens: wenn man Daten in diesem Volumen bewegt, will man das gar nicht monolitisch in einer Datei haben. Auslesen und Befüllen, Hoch- Runterladen will man in bequemen Häppchen machen, asynchron, internet / Bandbreitenfreundlich

4tens
"Da aber gerade MySQL voraussetz, dass sich alle seine Daten im selben Verzeichnis befinden .."
Vergiß diese Gedanken einfach, fast jedes RDBMS, dass mehr als eine Datei benötigt (also nicht SQLite, sondern alles was größer ist), erwartet einen Dateizugriff nach klaren Regeln. Die sollte man einhalten.
Datentransport erfolgt demnach per Backup/Restore, Export/Import, ..
Also egal wieviel Dateien und wo sie liegen und was (scheinbar) an oder aus ist, Datenbankdateien werden nicht kopiert, ob by mySQL oder anderswo (Ausnahmen habe ich genannt und sollten nur gemacht werden, wenn die Doku zweifelfreie Wege beschreibt, das zu tun)

Zu Deiner Frage: Für die Datenverwaltung ausschließlich mit gespeicherten Links (Basispfade + relative + Dateinamen) zu arbeiten wurde ja schon vorgeschlagen. Das scheint mir hier ein brauchbarer Ansatz, weil Zitat "kein Multiuserzugriff". Du musst also die Inhalte nicht besonders schützen (vor multiplen Usern) und kannst vermutlich bei Fehlbedienung oder Störung auch persönlich eingreifen und korrigieren.
Wenn Du mit solchen Links arbeitest, ist es dennoch sinnvoll, die Ziele der Links, Deine Dateien vor ungewollten Änderungen zu schützen.

[mkinzler]

Zitat:

... fast jedes RDBMS, dass mehr als eine Datei benötigt (also nicht SQLite, sondern alles was größer ist ...

Wobei die Anzahl der Dateien eines RDBMS ja nichts über es aussagt

[jobo]

nein, nicht viel, wie soll man das formulieren? Ab >1 ist mit großer Wahrscheinlichkeit ein innerer Zusammenhang der beiden Dateien gegeben und wenn es nur .ini und .data ist. Das scheint mir filigraner als 1x .sqlite oder .doc oder .xls
Und selbst die kann man zersemmeln.

[Delbor]

Hi zusammen

@Daniel:

Zitat:

Ich habe den Titel mal angepasst.

Vielen Dank dafür !

@alle: Herzlichen Dank für eure Antworten!

Ich nehme mir da noch etwas mehr Zeit, um mal alles etwas zu studieren. Aber grundsätzlich scheint mir das bis jetzt dahin zu gehen:
Meine Anwendung ist gewissermassen die "Zentrale". Und daher und auch aus Gründen der geplanten Client-Server-Kommunikation kann/sollte die selbst nicht auf SQLite aufbauen, sondern weiterhin auf MySQL.

Übrigens, um Missverständnissen vorzubeugen: Die Webserver-DB und diejenige meiner Anwendung werden nicht die selben Strukturen aufweisen; auf dem Webserver gibt es weder ein Feld für NEF-Dateien noch ein solches für Bitmaps. Vielmehr tendiere ich bis jetzt dazu, die Webinhalte selbst, also HTML, Jpeg, CSS und allfällige Javascripts da in Dateien abzulegen

@jobo:

Zitat:

Erinnere ich mich richtig, dass Du mit der mySQL DB "Schwierigkeiten" hattest, nachdem Du Dateien im laufenden Betrieb kopiert hast?

Ja.

Zitat:

Da dein Programm eigentlich wie ein DMS funktioniert und mit kein DMS bekannt ist, welches so große Dateien in seine DB speichert, solltest Du Dir vielleicht überlegen die Dateien nicht mehr in die DB zu packen, sondern extern und nur eine Verlinkung mit Tags und Co in der DB zu speichern.

Dann kannst Du auch SQLite verwenden..

Hmmm... Da muss ich jetzt doch zusehen, dass ich das richtig verstehe. Du sprichst da von einer Anwendungs-DB, die auch SQLite sein könnte? Und Dateien der benötigten Formate, die auf externen Festplatten vorliegen und deren Pfade in der Anwendungs-DB stehen?

Was spricht dagegen, diese Dateien statt direkt auf der Platte in einer eigenen DB abzulegen? Und zwar jeweils eine für Bitmaps (3 Felder: PK, Blob(Bitmaps), Boolean (un- bzw.bearbeitet) und eine für RAW-Bilder (3 Felder: PK, Blob(NEF) und Boolean (un- bzw.bearbeitet*). Klar, die Kommunikation dürfte so nur über eine OOP-Lösung möglich sein. Aber die beiden 'Datenbanken' könnten so auf verschiedenen externen Platten liegen.

In DataSnap selbst muss ich mich noch einarbeiten und kann mir desshalb noch keine Vorstellung machen, was damit alles möglich ist.

* Gibt an, ob es für das NEF-Bild schon eine Bitmap gibt.


Gruss
Delbor

[himitsu]

Bei DataSnap kannst du praktisch "Prozeduren" auf dem Server aufrufen, so als wären die direkt bei dir im Programm.

DataSet/Streams können dabei als Parameter/Result übergeben und abgefragt werden.
Bei dem Stream am anderen Ende muß man nur etwas aufpassen, da viele Dinge nicht damit zurecht kommen, wenn Stream.Size plötzlich mal -1 sagt.
Size ist nur >0 wenn alle Streamdaten in eine Netzwerkpaket passen. Sonst werden die Daten erst beim Abruft übertragen, so lange bis man beim Leseversuch (Read) 0 Byte zurück bekommt.
Aus diesem Grund hatten wir damals das DataSnap nochmal weggekapselt und kopieren die Streams nach dem Übertragen nochmal in einen MemoryStream um.

[Delbor]

Hi himitsu
Auch dir vielen Dank für deine Antwort! Datasnap wird wohl noch manchmal Grund liefern, hier Fragen zu stellen. So aus dem Stegreif erinnere ich mich gerade mal an eine sehr einfache Client-Server-Demo.
Datasnap und Demos, die mit Firedac arbeiten, ist allerdings auch einer der Gründe, wieso ich auf letzteres umgestiegen bin/umsteige.

Ich frage mich jetzt aber auch, ob nicht gerade Firedac eine mögliche Antwort auf meine Frage ist. Stichwort: TFDMemTable - aber da kann ich falsch liegen.

Gruss
Delbor

[Mavarik]

OK nur damit auch ich es verstehe...

Du willst eine externe Platte verwenden, weil Du nicht alle Daten gleichzeitig hast, richtig?

Der Server hat wieder anderen Datenbanken / Felder... Willst Du die Datenbank direkt auf den Karten der Kamera speichern?

Also Bilder die lokal vorliegen als Kopie in einen Datenbank zu speichern, macht für mich keinen Sinn... Also nur einen Pfad in die Datenbank oder die RAW-Daten erstmal Packen und dann in die Datenbank...

Die Übertragung zum Server würde ich - falls FTP keine option ist - entweder per SOAP (Einfacher in der Handhabung) oder per REST (weniger overhead) zum Server übertragen.

Mavarik

[Delbor]

Hi Maverik

Zum jetzigen Ist-Zustand:

• Meine Anwendung baut auf einer MySQL-Bilderdatenbank auf. Die Bilder sollen/werden von Festplatte (Dateien, extern, Festplatten oder Sandisk-Karten) im Rohdatenformat (NEF) eingelesen. Davon gibt es
• Bitmaps mit den Pixelabmessngen des Roh-Bildes (Originale Datenmenge zur Bearbeitung)
• Jpegs, grösste Seitenlänge max.(?) 1200px, Webseitenverträglich
• Daneben gibt es noch Tabellen/Felder für HTML, CSS und Javascript

Ideen zur weiteren Entwicklung:
Aufgrund der zu erwartenden Datenmenge/Dateigrösse der Bilder denke ich, sollten die beiden Formate auf externen Festplatten (In je einer DB? Je einer/mehreren Festplatten?) gespeichert werden, so dass die "Mutteranwendung" die Bilder zur Bearbeitung aus der NEF- bzw. Bitmapdatenbank lädt. Nef_Dateien werden dabei in Bitmaps konvertiert, so dass diese mit einem externen Programm zur Bearbeitung gestartet werden können.
Anschliessend wird die Bitmap in ein Jpeg konvertiert und in der DB der Mutteranwendung gespeichert.
Die bearbeitete Bitmap wird der Bitmap-DB übergeben und da gespeichert.
Die Mutteranwendung erstellt (bzw. der User) aus den in der DB vorgehaltenen Daten Webseiten (In je einer Klasse), denen der User per drag and Drop Bilder und Kommentare zuweisen kann.
Diese Webseiten bleiben in der DB gespeichert, entweder zur weiteren Bearbeitung oder um sie nach Fertigstellung an eine Webserveranwendung zu übermitteln.

Soweit mal ein kurzer Überblick, wobei der Listenabschnitt den Ist-Zustand wiedergibt. Der zweite Abschnitt enthält hingegen bereits einige Ideen zur Weiterentwicklung.
MySQL wird von meinem Hoster als Webseitendatenbank bereitgestellt, weshalb dies das DBMS für meine Webserveranwendung ist.
Auf meinem Rechner würde ich allerdings gerne SQLite einsetzen, wobei ich an eine solche DB für alle drei Anwendungen (Mutteranwendung, Nef-DB und Bitmap-DB) dachte. Mir ist bewusst, dass ich zum Datenaustausch eine OOP-Lösung benötige.

Noch zuwenig angesehen habe ich mir die vorgeschlagene NoSQL-Datenbank. Wobei - wenn ich mir das überlege, wäre ja eine Client-Server-Lösung mit DataSnap/FireDac und allenfalls SQLite eben eine NoSQL-Datenbank - laut Wikkipedia ist eine NoSQL-DB eben nicht unbedingt (oder gar nicht?) eine DB ohne SQL, sondern eine DB, die nicht ausschliesslich auf SQL aufbaut (zumindest, soweit ich das bisher verstanden habe).

Zitat:

Du willst eine externe Platte verwenden, weil Du nicht alle Daten gleichzeitig hast, richtig?

Nicht ganz. Die Gesamtheit der Bilddaten wird schnell mal zu gross. Diese füllen jetzt schon (zugegebenermassen etwas Chaotisch) eine Terrabyte-Platte. Dies zwar dank der Verarbeitung "von Hand". Trotzdem würden diese Bilder in einer DB-Lösung nicht viel weniger Platz beanspruchen.

Zitat:

1. Der Server hat wieder anderen Datenbanken /
2. Felder... Willst Du die Datenbank direkt auf den Karten der Kamera speichern?

1. Ja, die DB der Webserveranwendung wird ganz anders aufgebaut sein(User- und Sessionverwaltung etc)
2. Nein, da hat sie definitiv keinen Platz. Hingegen kommen sie von da, entweder direkt oder mit Umweg über die Festplatte.

Zitat:

Also Bilder die lokal vorliegen als Kopie in einen Datenbank zu speichern, macht für mich keinen Sinn... Also nur einen Pfad in die Datenbank oder die RAW-Daten erstmal Packen und dann in die Datenbank...

Tatsächlich liegen die Bilder noch als Dateien auf der Festplatte - dies allerdings nur sollange, bis sie in der DB sind und eine gute Backuplösung vorliegt. Was ist eine "gute" Backuplösung? Eine, die die vorhandenen Rohdaten speichert, oder eine, die dasselbe mit bearbeiteeten Bitmaps macht?

Zitat:

Die Übertragung zum Server würde ich - falls FTP keine option ist - entweder per SOAP (Einfacher in der Handhabung) oder per REST (weniger overhead) zum Server übertragen.

Danke für den Tip! Weniger overhead spricht doch schonmal für REST. Alenfalls müsste ich zusehen, wie gut ich das dann verstehe.

Gruss
Delbor

[mikhal]

Schon mal darüber nachgedacht, in deiner Datenbank nur "Thumbnails" vorzuhalten, um einen Eindruck des Bildes mitzugeben und die "richtigen" Bilder in den Verzeichnissen zu lassen, wo sie gerade sind oder wo sie bleiben sollen. Selbst bei einem Thumbnail von z.B. 200 Pixel Breite liegen die Daten als Jpeg bei einigen hundert KBytes pro Bild. Du speicherst dann noch zusätzlich den Pfad zum richtigen Bild und schön ist.

Ich sehe darin folgende Vorteile:

1. Die Datenbank bleibt überschaubar in ihrer Größe und die Datenbanksicherung ist in einem vernünftigen Zeitrahmen zu realisieren.
2. Die Sicherung der Bilddaten erfolgt über ein Backup-Programm, das zu verteilten Zeiten bestimmte Verzeichnisse oder Laufwerke sichert. Bei vernünftiger Planung mit regelmäßiger, zeitaufwendiger Vollsicherung und täglicher Differenzsicherung bis zur nächsten Vollsicherung kannst du sowohl den Speicherbedarf als auch den Zeitaufwand begrenzen.
3. Für mich schon fast das Totschlagargument gegen "Alle Daten in einer Datenbank": Du hast es ja bereits erlebt: Datenbank defekt - alle Daten futsch!

Bei deinem Vorhaben musst du sowieso von einem echten Client-Server-Umfeld ausgehen, du benötigst enorm viel Speicher, egal wie du dich entscheidest. Technisch ist deine Datenflut, mit der du ja rechnest, nur mit einem entsprechenden Speichersystem zu begegnen - sei es ein SAN oder ein NAS.

Die Verteilung auf mehrere Platten / Speichermedien lässt sich am einfachsten über die Trennung deiner Bilder von deiner Datenbank realisieren. Dann ist es schon fast egal, welches Datenbanksystem du einsetzt.

Grüße
Mikhal

[Delbor]

Hi mikhal

Zitat:

Schon mal darüber nachgedacht, in deiner Datenbank nur "Thumbnails" vorzuhalten,

JA, habe ich.
Sir Rufo hat mir damals den Vorschlag gemacht, mit GUIDS zu arbeiten.

Der aktuelle Stand ist demnach: es gibt kein Feld für NEFs mehr in der DB, für Bitmaps hingegen schon:

Delphi-Quellcode:

function TFDMySQLDml.BildInsertQuery(BJpeg: TJPEGImage; WorkMap : TBitmap; LIdFolder: String): integer;
  var  SQLString: string;                //  BJpeg,
begin
  SQLString := 'Insert Into Bildtabelle(Thumbnail, Bitmap, FolderID) Values (:BJpeg, :Workmap, :LIDFolder)';
  FDQueryMain.SQL.Text := SQLString;
  FDQueryMain.Params[0].Assign(Bjpeg); 
  FDQueryMain.Params[1].Assign(Workmap);
  FDQueryMain.Params[2].AsString := LIDFolder;
  FDQueryMain.ExecSQL(false);
  if FDQueryMain.Active then
     FDQueryMain.Close;
  SQLString := 'Select Last_Insert_ID()AS LastID';
  FDQueryMain.SQL.Text := SQLString;
  FDQueryMain.Open;
  if not FDQueryMain.IsEmpty then
    result := FDQueryMain.FieldByName('LastID').AsInteger;      //
end;

Dabei wird in der aufrufenden Methode das NEF in ein TPicture-Objekt geladen, dieses dann in 2 TBitmaps, wovon eine skaliert und in ein Jpeg konvertiert wird. Das NEF-Bild wird anschliessend verworfen.
Es mag doof klingen, aber mit der TGuid-Lösung kann ich mich nicht wirklich anfreunden. Und zwar, weil dieser GUID nun in allen jenen Bildverzeichnissen steht, die schon mal eingelesen wurden. Das bedeutet: Wenn die Bilder, aus welchem Grund auch immer, neu eingelesen werden müssen, muss das Programm erstmal per Abfrage ermitteln, ob die Bilder in der DB sind oder nicht - und das verlängert die Zeit für Insert-Statements.

Andrerseits habe ich mir auch mal TFDMemTable angesehen. Das Schöne daranist: das Ding kann seinen Inhalt von der Patte laden und auch dahin speichern. Das Schöne daran ist: dieses Ding selbst ist, soweit ich das bisher verstanden habe, unabhängig vom verwendeten DBMS.

Und wenn ich mir die einzelnen Festplatten-Ordner und deren durchschnittliche Gösse ansehe (etwa 3GB für NEF-Ordner und rund das dreifache für Bitmap-Ordner (10 - 11GB) und das mit der Grösse meines neuesten USB-Sticks vergleiche (64GB), dann kkommen mir da einige Ideen...

Das heisst aber auch, dass es gar keine Datenbanken auf externen Laufwerken braucht - die sind je nach Zielsetzung eventuell bloss wünschbar...


Gruss
Delbor