Datenbanken auf externe Platten auslagern?

[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