Storing data on the file system and in the database weekens the data model. You can't impose a not null constraint for the file for example. Also the file system is not a transactional resource. If you create a record in the database pointing to a file and the file save stage fails you'll have to handle the rollback manually. Another thing is the file system is a difficult resource to access from a distributed environment - at the bare minimum you are probably going to have to introduce some OS specific access stuff (i.e. different UNC syntax) plus some admin overhead to maintina a share or how ever you implement this.
Also, whats the difference between blob and clob, other than one being binary? A difference in layman's terms.
A blob == Binary large object, i.e. any binary data. Clob == Character large object i.e. specifically character data. [ May 09, 2007: Message edited by: Paul Sturrock ]
So, does it imply that there are no performance advantages of blob over file systems? In most of the projects, i have seen files being stored on hdd and paths being held in db. Does this have anything to do with number of files or size of files?
Thanks for the transactional implications of a file system storage.
So, does it imply that there are no performance advantages of blob over file systems?
There will probably be a performance difference. But these differences (as with most performance issues) will be very much specific to your environment. I would guess that there is a bigger overhead streaming the file into the database before the database persists it to the file system simply because using the file system direct misses the DB step. Performance is a smaller concern than some of the other issues I highlighted though.