Here are some of my inputs to stand "FOR OUTSIDE DB"
It purely depends upon your need. If your business wants to keep them always available and recoverable with no down time then you might have to think a proper option to keep them available 24/7, but keeping them in Database the capacity management of DB server will be in question.
If no priority for your need then I would say better to keep raw files in appserver, just the location of the file in DB server in terms of
varchar would help and adding index to it would benefit to get the right file location quicker even the number of rows are more. Imagine you have each field consisting of 1GB text and for 100 rows the size of the table would go more than 100GB. Sounds weird for me when I need to take care of everything like how DB performs when it comes to time taken for recovering the Database in-case of shutdown / backup / High Availability and over all performance of DB server.
I haven't got an opportunity to design such a requirement. But if given
- I would keep them in app server as each files in file system.
- Keep the file locations in tables as
- Let the application logic to generate the file locations in the order of the design pattern you want according to your server
- Keep the raw file mount point hard link to another server with same file naming nomenclature, in-case of disaster of your files use the
fail over server IP for the application to point.
By this way DB performance will look good, quick recovery and data availability 24/7 and less time spent in-case of any maintenance activities.