Could it be a much better practice to keep media files (documents, video, images, and finally executables) within the database itself, or must i just put a hyperlink for them within the database and store them as individual files?
Read this whitened paper by MS research (to BLOB or otherwise to BLOB) - it is going thorough concerning the question.
Executive summary - for those who have plenty of small (150kb and fewer) files, you may as well store them within the DB. Obviously, this suits the databases these were testing with and taking advantage of their test methods. I would recommend reading through the content entirely to a minimum of obtain a good knowledge of the trade-offs.
That's a fascinating paper that Oded has associated with - if you work with Sql Server 2008 using its FileStream feature the final outcome is comparable. I've cited a few salient points in the linked FileStream whitepaper:
"FILESTREAM storage isn't appropriate in most cases. According to prior research and FILESTREAM feature behavior, BLOB data of size 1 Megabytes and bigger that won't be utilized through Transact-SQL is most effective to storing as FILESTREAM data."
"Consideration should also get towards the update workload, every partial update to some FILESTREAM file will produce a complete copy from the file. Having a particularly heavy update workload, the performance might be so that FILESTREAM isn't appropriate"
Storing BLOB data in database isn't considered right approach to take unless of course they're really small. Rather storing their path is much more appropriate. it'll greatly improve database query and retrieval performance.
Two needs drive the response to your question:
- Can there be several application server reading through binaries in the database server?
- Have you got a database connection that may stream binaries for write and browse?
Multiple application servers tugging binaries in one database server really hinders what you can do to scale. Take into account that database connections are often - always - from a more compact pool compared to application servers' request maintenance pool. And, the information volume binaries will consume being sent from database server to application server within the pipe. The database server will probably queue demands because its pool of connections is going to be consumed delivering binaries.
Streaming is essential to ensure that personal files isn't completely in server memory on read or write (appears like @Andrew's answer about SQL Server 2008 FILESTREAM may talk to this). Make a file several gb in dimensions - if read completely into memory - could be enough to crash many application servers, which just not have the physical memory to support. Without having streaming database connections storing within the database is actually not viable, unless of course you constrain quality so that the application server software programs are allotted a minimum of just as much memory because the max quality * quantity of request maintenance connections + some additional overhead.
Now let us say you do not place the files within the database. Most os's are extremely proficient at caching frequently utilized files. So quickly the softball bat you receive an additional benefit. Plus, if you are doing web servers, they're very good at delivering back the best request headers, for example mime type, content length, e-tags, etc... that you simply otherwise finish up coding yourself. The actual issues are replication between servers, but many application servers are very good at carrying this out via http - streaming the read, so that as another answerer stated keeping database and file system synchronized for backup copies.
Here's detailed comparison I've made http://akashkava.com/blog/127/huge-file-storage-in-database-rather-of-file-system/