Store in the database with a blob
A disadvantage is that it makes your database files quite large and possibly too large to back up with your existing set up. An advantage is integrity and atomicity.
Store on the filesystem with a link in the database
I’ve come across such horrible disasters doing this, and it scares me that people keep suggesting it. Some of the disasters included:
- One privileged user who would rearrange the files and frequently break the links between the paths in the DB and where they now are (but somehow this became my fault).
- When moving from one server to another, the ownership of some of the files was lost as the SID for the old machine’s administator account (what the old website was running on) was not part of the domain and so the copied files had ACLs that could not be resolved thus presenting users with the username/password/domain login prompt.
- Some of the paths ended up being longer than 256 characters from the
C:all the way to the
.docand not all versions of NT were able to deal with long paths.
Store in the filesystem but rename to a hash of the contents and store the hash on the database
The last place I worked at did this based on my explanation of the above scenarios did this. They thought it was a compromise between the organization’s inability to obtain experience with large databases (anything larger than about 40G was ordained to be “too big”), the corporate inability to purchase large hard drives, and the inability to purchase a more modern back up solution, and the need to get away from risks #1 & #3 that I identified above.
My opinion is that storing in the DB as a blob is a better solution and more scalable in a multi-server scenario, especially with failover and availability concerns.
Number 1 for complete data integrity. Use the other options if you don’t care about data quality. It’s that simple.
Most RDBMS have optimizations for storing BLOBs (eg SQL Server filestream) anyway
If going for oracle, take a look at dbfs and Secure Files.
Secure Files says it all, keep ALL your data safe in the database. It is organized in lobs. Secure Files is a modernized version of lobs, that should be activated.
dbfs is a filesystem in the database. You can mount it similar like a network filesystem, on a Linux host. It is real powerful. See blog It also has a lot of options to tune to your specific needs. Being a dba, given a filesystem (based in the database, mounted on Linux), I created an Oracle Database on it without any problems. (a database, stored in a … database). Not that this would be very useful but it does show the power.
More advantages are: availability, backup, recovery, all read consistent with the other relational data.
Sometimes size is given as a reason not to store documents in the database. That data probably has to be backed up any way so that’s not a good reason not to store in the database. Especially in a situation where old documents are to be considered read only, it is easy to make big parts of the database read only. In that case, those parts of the database no longer have a need for a high frequent backup.
A reference in a table to something outside the database is unsafe. It can be manipulated, is hard to check and can easily get lost. How about transactions? The database offers solutions for all these issues. With Oracle DBFS you can give your docs to non database applications and they wouldn’t even know they are poking in a database.
A last, big surprise, the performance of a dbfs filesystem is often better than a regular filesystem. This is especially true if the files are larger than a few blocks.