File systems as databases is an old tact and not always invalid depending on the purpose.
The big differentiator is your use, if you're going to have frequent writes (especially updates) such as in a highly transactional system, you do not want to use a file system as this will require a lot of synchronizing multi-user access. Furthermore databases are made specifically for this purpose having optimizations like caching multiple updates/writes to thunk bulk-writes for better network throughput not making users wait on disk IO completions, caching in memory highly transactional data etc as well as countless tricks tuned and optimized for decades now to make use of disk IO in the most efficient way as possible.
Now then, when is this approach valid? For largely read-only blobs, and especially when you are capable of a strategy where you cache them in-memory in a way that minimizes how often they are read from disk, especially if there is any form of serious load. For instance, if it's a web-server, most web-servers have built in well-tuned strategies for doing this with frequently requested static data which you merely need to turn on for the URL those blobs are available from.
In either scenario, the network location of your database and or files related to database are to be treated the same: Locked down as all get out. You do not allow access to these resources as someone may trash your database, or those files which are related to the database and therefore a part of the database in truth; moving/deleting/renaming/altering them is the same as doing so on a database record. Treat security accordingly.
Further knowledge regarding blobs on a per database system basis is also important, for example in SQL Server if you have a blob column in a table depending on how it's setup, it may use an entire page for every single record regardless of actual record size, further it may move the blob portion of the record off the page to another page of the data file altogether, these factors should be studied when designing a table with blob columns to make sure you aren't causing the database to work less efficiently than it could with a different table design.
Side note, when storing blobs in the database, whichever tables they go in it's a good idea to place those in separate file groups from other portions of the database so they can be moved to larger LUNs over time as their growth outpaces the rest of your database, and to help them not interfere with IO or query performance of the rest of your database.