Bei der Frage
ob die Dateien als BLOBs gespeichert werden sollen, ist auch wichtig, ob externe Tools darauf zugreifen müssen. Bei Bildern könnte das z.B. eine Kommandozeilen Tool zum Skalieren sein. Oder ein Webserver der die Dateien direkt ausliefert.
Bei Oracle BLOBs ist ganz wichtig diese als
"SECUREFILE" zu definieren, da sonst die Speicherung sehr ineffizient ist.
Wenn ihr viele UPDATEs auf die BLOBs habt, dann müsst ihr auch die Einstellungen für RETENTION an den Spalten fein-tunen, da BLOB Updates bei Oracle nicht über das normale UNDO Log laufen, sondern einfach eine neue Kopie des BLOB gespeichert wird. Das kann bei vielen UPDATEs zu einem überproportionalen Anwachsen des Tablespace führen.
Sinnvoll ist sicher auch die Kompression dafür einzuschalten (dafür ist aber eine Enterprise Edition notwendig!) - nutzt natürlich nichts wenn die Dateien schon komprimiert sind (z.B. JPGs oder ZIP Archive).
Ich würde auch einen eigenen Tablespace dafür einrichten, damit der "normale" damit nicht aufgebläht wird.
Sowas in der Art:
Code:
create table media
(
id integer primary key,
blob_data blob
)
lob (blob_data)
store as securefile
(
tablespace blob_data
compress high --- Achtung EE notwendig!!
retention auto
nocache
);
Unter Umständen sogar " retention none" verwenden. Das könnte z.B. bei lang laufenden Transaktionen und gleichzeitigen Zugriff auf "snapshot too old" Fehler hinauslaufen, braucht aber deutlich weniger Speicherplatz.
Das nocache sorgt dafür, dass das Lesen von großen Daten nicht durch den Buffer Cache geht und ein einzelner großer BLOB viele andere Datensätze aus dem Cache verdrängt.
Wenn ihr damit rechnet, dass die gleiche (=identische) Datei mehrfach gespeichert wird, könnte man auch noch die "DEPLUCATION" einschalten (auch dafür ist die Enterprise Version erforderlich!)
