> ... however when you start to have 5000 or more images and > are growing them at hundreds per day it seems like the > database is a good place as opposed to the file system that > can't handle the mass of files and would requires some pretty > nifty subdirectory flexible management and growth building > algorithm...
It doesn't have to be that nifty, actually. Here's a five-minute solution. Have your app create year folders, month folders within them, and day folders within them, and you'll be able to store quite a few files without any filesystem lookup troubles. You could have the folders created on demand, or on a scheduled basis, or you could write a script to do this for some period in advance, or whatever. > Additionally, putting meta data with the file and within the > file and in the database makes it all queryable You can still store all the metadata you want in the database, so this doesn't make any difference, unless you're using something beyond regular SQL to search image content (image pattern analysis, or something like that). > and nice so we can move/backup one large chunk instead of > 5000 files plus database :) Admittedly, it's easier to manage one file than many files, but you're going to pay a price on the database end. Usually, that price isn't worth it. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Get the mailserver that powers this list at http://www.coolfusion.com FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
