Ich weiß nicht, ob das eine gute Idee ist.
Es geht natürlich, alle Form von Binärdaten können in einer
DB abgelegt werden.
Fachlich geht das aber am Nutzen einer
DB vorbei und produziert eine Menge Overhead, der durch Hardware, Caching, .. "bekämpft" werden muss.
M.E. ist das primäre Interesse bei einer Dokumentenablage nicht, das Dokument selbst in der
DB "sicher" abzulegen, sondern maximal dessen Metadaten. Also allerlei Dokumenteigenschaften, ggF. Textinhalt, Volltextindex, Bildquellen, Referenzen, ..
Was man natürlich vordergründig einfach erreicht, ist der Schutz des Dokuments selbst. (Eben zu einem relativ hohen Preis)
Diesen Schutz -sagen wir mal Zugriffs und Manipulationsschutz- kann man auch erreichen, indem man einen normalen Fileserver nimmt, dessen Zugriffsrechte nur dem DBServer oder einem zwischengeschalteten Applicationserver gegeben sind.
Klassischer Fall von / für Dokumentenmanagement-Systeme. Besonders dann, wenn es um Nachweispflichten etc. geht und man entssprechend zertifizierte DMS einsetzt.
Allein folgendes Gedankenexperiment macht vielleicht nachdenklich:
Die Transaktionssteuerung der
DB, die Rollbackmöglichkeit, die inkludierte "Fehlertolleranz" erfordern es, alle Datenbewegungen zu loggen und vorwärts, rückwärts reproduzierbar zu machen. Bei normalen Datensätzen ist das kein Problem, bei dicken Binärdaten auch nicht, diese sind allerdings meist statisch, es wird ein Haufen Änderungen gechrieben wobei die Änderung selbst nur ein paar Byte beträgt. Ein PDF, was Du in die
DB schickst, "vervielfacht" sich dabei aus Volumenperspektive u.U. bis hin zum stark vergrößerten Backupvolumen der
DB. Eine Korrektur von ein paar Metadaten (in der gleichen Tabelle, in der das PDF liegt) erzeugt dann immer neue hohe Backupmengen.