Das kann Firebird sehr wohl und wir machen genau den Ansatz schon so seit Jahren, mit Blobdatenmengen bis hin in den Terabyte Bereich (Ich geh mal davon aus, das dein Begriff Dokument als Blob zu verstehen ist, also pdf oder sonstwas)
Genereller Ansatz:
-Du speicherst deine blobs (pdfs etc.) am besten in eigene Tabelle, in den Tabellen die dazu gehören packst du zum Beispiel nur den fk zu dem Blob in der Blob Tabelle
-Wenn ein neuer Blob inhalt gespeichert werden soll, speicherst du den ganz normal in deiner aktiven Produktionsdatenbank
-Wichtig: wenn dein Client auf einen Blob Inhalt später lesend zugreift, dann machst du das nicht direkt per select auf der Tabelle, sondern über einen select auf einer sp, die den PK als parameter bekommt (ich nenn die hier mal getblob, ist aber nichts eingebautes, sondern ganz simpel selber zu erstellen)
-Du legst dir entweder jährlich oder in welchen Arten auch immer extra DBs an, in denen nichts als die blob tabelle baugleich ist (B2020.fdb, B2019.fdb, B2018.fdb usw)
-In einem simplen Reorg job, der zum Beispiel jede Nacht auf deiner Produktions
DB läuft, schiebst du die blob daten, die z.B. älter als x Tage sind oder wie bei uns alle die gestern oder noch älter sind von der Produktions
DB in die aktuelle offene Jahres
DB (diese ist readwrite)
-Das übertragen geht per execute statement on external in einer sp oder einem execute block transaktionssicher, also delete in production und insert into jahres
db ist ein einziger commit, obwohl 2 dbs
-Wenn du einen blob lesen willst, kann anhand der blob tabellen metadaten (timestamp) erkannt werden, wo die zu finden sind. Deine sp getblob macht nun als nicht anderes, als die metadaten zu dem blob auszulesen und per execute statement on external den eigentlich blob inhalt aus der jahres
db in den speicher der production
db holen und von da als rückgabe von der sp im client anzeigen, in datei packen oder was auchimmer damit machen.
-am jahresende setzt du die jahresdb auf readonly, select mit execute statement on external geht weiterhin, es muss nicht mal eine
db auf dem eigenen server sein, sondern kann irgendwo aus der cloud kommen. Deine Getblob sp kann ja zu den metadaten irgendwelche Connectionstring aus einer tabelle auslesen und die dann benutzen.
-archivierte readonly jahresdbs packen wir auch meistens nicht auf schnelle ssds, sondern durchaus auf große hdds, weil die nur ein mal beim read only setzen gesichert werden müssen und dann nie wieder, weil die ja auch nie wieder geändert werden. Da alte Dokument selten geschwindigkeitskritisch sind, reciht das auch von hdds.
Wenn Interesse besteht können wir genau das Thema auch gerne mal nächsten Mittwoch um 17 Uhr im Stammtisch besprechen, weil ich weiss, das viele so eine Anforderungen haben und gerne den ganzen Kram in die db packen, aber dann in Probleme laufen, wenn die db nach wenigen Monaten oder Jahren dann dutzende oder hunderte Gigabyte haben und Backup/Restores endlos dauern.
Ganz wichtig aus meiner sicht: Mit "Nicht Blob Daten" ist das Mumpitz, geht auch, z.B. per datebase trigger oder table trigger, ist aber dann extrem umständlich, damit foreignkey beziehungen in abfragen sauber über mehrere Datenbank abzubilden und bringt nichts an Speed, ganz im Gegenteil.