Netfrastructure had a large law firm that went paperless. All
correspondence was generated by the application and stored in the
database as a PDF blog. All incoming correspondence was scanned in the
mail room and stored in the database as a blob. The amount of daily
blob data was enormous, and commingling blob data with table and record
data was infeasible.
The architecture I developed to address the problem was this:
1. DDL to declare blob repositories. Each repository a name, a file
name pattern, and a target size.
2. The blob DDL allowed specification of a named repository to hold
instances of that blob.
3. Each repository managed an open ended set of volume (file). When a
repository volume reached the the repository's declared target size,
the current volume would closed and a new volume created using the
declared file name pattern.
4. A repository volume used the same ODS as the primary database file
but was logically independent.
5. Blob references were variable length with encoded repository name,
volume, and id in volume
The driving factor for the complex blob reference was the database
replication scheme that guaranteed that repository volumes would be
interchangeable among database replicants so a lost, damaged, or offline
volume could be copied from another system.
In practice, nothing was ever deleted from a blob repository other than
a backed out transaction, but blob garbage collection applied to
repository blobs as run of the mill blobs.
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://makebettercode.com/inteldaal-eval
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
