I don't think you would see any performance penalty if you don't SELECT the IMAGE field in a particular query. It would be worth some testing to be sure.
However, I like the idea of a very small table that would hold only minimal information. On the other hand, I would put as much in the same table as the IMAGE field just to be safe. All of this information, and maybe some more, cannot really exist without the rest of the record. I would store: id origFileName contentType contentSubType fileSize binaryContent insertDateTime insertUserName comment M!ke -----Original Message----- From: Zaphod Beeblebrox [mailto:[EMAIL PROTECTED] Sent: Friday, February 10, 2006 3:31 PM To: CF-Talk Subject: Re: Storing Documents We've got two tables set up: search_table :id :metadata1 :metadata2 :metadataN :file_type :file_size :file_id file_storage :id :image everything is stored in the database. The tables could have been combined into one, but we thought it might slow down performance if your having to deal with a blob object in all of your queries. The way we have it set up, we can run queries against the lightweight search_table and then retrieve the document from the file_id => file_storage.id relation. Also, given this technique, the file_storage table could easily be moved to another database, another server, or spread out to different databases. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:232013 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
