Page 1 of 1
Best way to manage photos
Posted: Thu Dec 20, 2007 7:11 pm
by arpowers
Hey guys,
What is the best method of managing photos with a php/mysql application??
I've done a little looking around and it seems like some use a database and other use directories...
can anybody straighten me out?
Thanks!

Andrew[/s]
Re: Best way to manage photos
Posted: Thu Dec 20, 2007 9:09 pm
by califdon
arpowers wrote:Hey guys,
What is the best method of managing photos with a php/mysql application??
I've done a little looking around and it seems like some use a database and other use directories...
can anybody straighten me out?
Thanks!

Andrew[/s]
You don't need straightening out (as far as I know), it's just that there is no single or simple answer to your question. There are two options: store images as blobs in a table, and store path/filename pointers to wherever the images are stored as files.
If you have very large numbers of very large images, storing them in a table might cause a performance problem. If you store them as files, problems can arise from the files or their paths being changed or the files can be deleted without updating the table. So your choice will depend on the relative importance of such factors. That's why some use one option and others use another option.
Posted: Fri Dec 21, 2007 9:45 am
by pickle
I think more often than not, you're going to hear the same thing from experienced developers - keep the files in the filesystem. The performance gain is huge. I had one photo repository system that started out using the database as the storage medium. It had about 900 100x100 images (not very large). The second version used the filesystem & was about 2-3x faster than the database version. Development was marginally more complex, but very worth it.
Posted: Fri Dec 21, 2007 11:43 am
by Inkyskin
Yeah, I hate storing images in a database. OpenAds does this by default, and it's hell.
Posted: Fri Dec 21, 2007 4:12 pm
by Mordred
With huge amounts of images, consider putting them in a wide tree of subdirectories, or you'll run into the limits of the underlying file system.
Posted: Fri Dec 21, 2007 4:22 pm
by s.dot
@mordred - not really. At least from what I've noticed. On a freebsd platform I easily had over 100,000 images. Performance was no problem. The problem came when opening the folder and reading the contents. Plus, by default, most ftp clients only like to read 2000 file entries. I backed up my site on a windows drive, and php had no problems accessing the images directly, but opening the folder was hellacious. I don't know how this would scale if the images were into the million+ count, but I wouldn't see a reason for problems.
However, it's suggested that you organize your image file system as much as possible.
IE.
images/
images/full/
images/thumbs/
images/full/user/
images/thumbs/user/
Or use the date instead of user.. something that's easily navigable and relatively easy to determine what's inside the folder.
Posted: Fri Dec 21, 2007 5:15 pm
by feyd
Windows generally (at least in older, than Vista, versions) had performance drops at multiples of 500 items per folder or something. Systems which are accessed heavily should be split apart too, to help performance.
Posted: Fri Dec 21, 2007 9:05 pm
by yanglei1979
very easy.
I have been developing such a system.
Posted: Sun Dec 23, 2007 10:17 pm
by Kieran Huggins
y'all know I like to store data as the md5 of it's contents. If I have a system where there will be more than a few thousand files I store in alphabetical directories based on he first so many characters, like so:
Code: Select all
0/a/a/0aa1ea9a5a04b78d4581dd6d17742627
1/9/6/196b0f14eba66e10fba74dbf9e99c22f
b/5/b/b5b037a78522671b89a2c1b21d9b80c6