My general "rule of thumb" (there's that awful expression again) is: lots and lots and lots of files => database or specialised file system not so many files => any old file system All sorts of caveats though, eg, if you're storing file metadata in the database, then you might want it all in there to ensure conherency if you need to restore to a point in time. Its relatively straightforward to drag a PDF out of the database and present it to a browser via dbms_lob. hth Connor On 10/20/05, Murching, Bob <bob_murching@xxxxxxxxx> wrote: > > We design a fair number of J2EE applications that (increasingly) require > storage and query/presentation of binary documents.... generally PDFs. > Occasionally our DBAs have been consulted with that age-old "should we store > these in the database or on a filesystem?" question by developers and > analysts when designing the application. So far we've tended to put them on > the filesystem but honestly that's because we don't have any guidance on > when it makes sense to store them in the DB. > > Obviously Oracle provides a level of security, access control and > auditing, along with (arguably) backup and recovery capabilities that might > surpass filesystem storage. Manageability is easier when volumes reach the > tens of thousands of files. On the other hand, there is a concern that > putting tens of thousands of objects in BLOB columns can impose some > performance overhead... perhaps inefficiencies in JDBC, or within Oracle > RDBMS itself, or ... ? It certainly is "simple" to dump the PDFs on the > filesystem and storage file paths in a table. > > Anyone else run into this? In which direction have you leaned and how do > you decide? And can anyone speak to what considerations should be kept in > mind when storing documents in BLOBs and querying them via JDBC, for either > browser presentation or manipulation in the midtier? > > Bob > -- Connor McDonald =========================== email: connor_mcdonald@xxxxxxxxx web: http://www.oracledba.co.uk "Semper in excremento, sole profundum qui variat"