Also auch nochmal meinen Senf dazu:
Die eigentlichen Daten werden getrennt von den Blobs abgelegt.
Je Bild wird die MD5-Checksumme errechnet, das geht bei den kleinen Bildern schnell, entsprechendes liefert Delphi.
Die Bilder kommen in Blobs einer Tabelle, die neben dem Blob nur noch die MD5-Checksumme hat. Da kommt ein eindeutiger Index drauf. Doppelte MD5-Checksummen weisen auf identische Blobs hin, die brauchen wir nicht.
Der Datensatz, zu dem ein Blob gehört, enthält ebenfalls die MD5-Checksumme.
Wird nun für einen Datensatz das Bild angefordert, so nimmt man aus dem Datensatz die MD5-Checksumme und sucht in der "Blob-Tabelle" und hat sein passendes Bild.
Die Beschreibung dessen, was gemacht werden muss, ist vermutlich deutlich länger, als der zur Umsetzung erforderliche Quelltext.
Gehören mehrere Bilder zu einem Datensatz, dann muss man sich noch eine "Zwischentabelle" machen, die einerseits den Schlüssel der Daten enthält und daneben die MD5-Checksumme des Bildes. Damit kann man dann das 1:n-Verhältnis zwischen Daten und Blobs aufzulösen.
450.000 * 15 kb = 6.750.000 kb = ca. 6.750 MB oder knapp 7 Gigabyte + unbekannter Verwaltungsoverhead der Datenbank. Das ist in heutiger Zeit keine so exorbitante Datenbankgröße.
Und ja: Der Vorschlag zu testen ist sinnvoll. Und wenn nur mal die weiter oben vorgeschlagenen minimale Tabellenstruktur erstellt wird und dann ein Bild 100 oder 200k mal in die Datenbank gepumpt wird, mit 'nem erstmal nur Autoinc (oder ähnlichem) als eindeutigem Schlüssel. Und dann mal ein paar hundert Selects drauf loslassen und schauen, wie lange die Antwortzeit so ist. Und dann mal schauen, wie schnell oder langsam das Einfügen weiterer Kopien des Blobs wird.
(Da die Blobs im Produktivbetrieb aber nur einmal erstellt werden, dürfte eine Zeitverzögerung beim Speichern aber immernoch im akzeptablen Bereich bleiben.)
Und wenn dieser Minimalaufbau zu Ergebnissen führt, die inakzeptabel sind, dann weiterforschen.
Meine tausende Texte in Blobs dauern, wenn etwas größer, schon ein bisserl beim Speichern, das Lesen ist (fast vernachlässigbar) schnell und alles liegt in einer Datenbankdatei, keine Trennung von Daten und Blobs in irgendeinen anderen Bereich (oder sowas), alles in der einen Datenbankdatei.
Da die Bilder nur einmal in die
DB geschrieben werden sollen, und dann nur noch gelesen werden, würd' ich mit Firebird ein insgesamt schnelles System, mit relativ wenig Programmmieraufwand, erwarten.