I recommend storing each contract in its own directory, as you might have had it until now, and let the database be used for organizing the metadata (including hierarchy stuff) on top of the file system.
Then you leverage the best of both worlds. That's my $0.02 dov -----Original Message----- From: Michael T. Tangorre [mailto:[EMAIL PROTECTED] Sent: Friday, February 10, 2006 11:34 AM To: CF-Talk Subject: Storing Documents I have never stored actual documents in SQL Server. I have stored the name and location and put the document into a directory on the file server. However, a new "contracts" application I am working on is very document heavy, mainly for storage... not much retrieval will be done. Currently when a new contract comes to be, a directory is created for the contract and a slew of sub directories are also created over the life of the contract. Sometimes the sub directories are standard across contracts and some times they are not. Sub directories can get pretty deep in terms of nesting. It seems it would be much easier (conceptually) to store the documents directly in the database and let the structure of the database dictate the "hierarchy" and relationships instead of creating a new directory for each contract and trying to figure out which subdirectories are needed or already exist, etc. When needed, the documents would be accessed via the application... however this would restrict direct access to the document outside the system. Anyway, has anyone taken the approach of storing documents directly in a SQL DB, and if so, how was performance etc... Thanks! Tango ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:231935 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
