On Thu, Feb 09, 2006 at 07:18:49AM -0800, Craig A. James wrote: > Nate Byrnes wrote: > >I must claim some ignorance, I come from the application world... but, > >from a data integrity perspective, it makes a whole lot of sense to > >store video, images, documents, whatever in the database rather than on > >the file system external to it. Personally, I would use LOB's, but I do > >not know the internals well enough to say LOBs or large columns. > >Regardless, there are a lot of compelling reasons ranging from software > >maintenance, disk management, data access control, single security layer > >implementation, and so on which justify storing data like this in the > >DB. Am I too much of an Oracle guy? > > Yes, you are too much of an Oracle guy ;-). Oracle got this notion that > they could conquer the world, that EVERYTHING should be in an Oracle > database. I think they even built a SAMBA file system on top of Oracle. > It's like a hammer manufacturer telling you the hammer is also good for > screws and for gluing. It just ain't so. > > You can store videos in a database, but there will be a price. You're > asking the database to do something that the file system is already > exceptionally good at: store big files. > > You make one good point about security: A database can provide a single > point of access control. Storing the videos externally requires a second > mechanism. That's not necessarily bad -- you probably have a middleware > layer, which can ensure that it won't deliver the goods unless the user has > successfully connected to the database. You're forgetting about cleanup and transactions. If you store outside the database you either have to write some kind of garbage collector, or you add a trigger to delete the file on disk when the row in the database pointing at it is deleted and hope that the transaction doesn't rollback. Of course, someone could probably write some stand-alone code that would handle all of this in a generic way... :) -- Jim C. Nasby, Sr. Engineering Consultant jnasby@xxxxxxxxxxxxx Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
