![]() As far as I'm aware, that's not possible in any scenario with any DBMS. If what you store in the database are file paths, you are afforded the ability to change those to paths at S3. Suppose one day you want to store your files in an Amazon S3 bucket. You cannot take advantage of cloud storage.Again, adding a handler is not impossible but adds complexity and is another point of failure. You can also do this even if you store file paths but you don't have to do this. In order to do it with binary columns, you have to write a handler to stream the file binary from the database. It is more complicated to serve up the files to a website.When you store files on the file system, there isn't an additional layer involved to wrap/tweak/alter the source file. Extracting those Ole Object's was a new level of hell. Much later someone changed the interface to store the raw binary. Later they changed to use a different control which still relied on Ole. One company for whom I consulted not so many moons ago at some point connected a Microsoft Access frontend to their database server and used Access' ability to upload "anything" using its Ole Object control. The code that writes the files to the database can be a problem.Portability can be a concern if you use system specific features like SQL Server's FILESTREAM object and need to migrate to a different database system.Larger databases also consume more memory as they try to stuff as much data into memory as possible. None of these things are impossible to learn, but do add complexity to maintenance which means cost to the business. You may have to consider putting the files on a different file group (if the database supports that), tweak the backups to separate the backup of the data from the backup of the files etc. Even if say a daily full backup would have sufficed, with a larger database size, you may no longer be able to do that. Storing the files in the database can make the database much larger. I.e., large databases are more complicated to maintain than small databases. One general concept you should take to heart: The level of knowledge required to maintain a database goes up in proportion to the size of the database. If users need to store files larger (like say a movie), you have to jump through hoops to make that magic happen. On SQL Server, when not using the FILESTREAM object, for example, it is 2 GB. The size of a binary file differs amongst databases.Reason against storing files in the database: Backups automatically include the file binaries.Files go with the database and cannot be orphaned from it.Having the files and database in sync and able to participate in transactions can be very useful. ACID consistency including a rollback of an update which is complicated when the files are stored outside the database.Reasons in favor of storing files in the database:
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |