Image storage.

[MinusMyThoughts]

i'm trying to allow my user to update all of the content, including the images on the site. on my current project, there are three images on the main site and a handful of 75x75 images that will go up with testimonials......the reference book i've got only tells me how to upload a text file into a folder. i think i'd be able to put the images in a folder, but i'd rather have them in a database. if you know a reason to use a folder instead, i'm all ears; i've barely learned MySQL, so i want to put everything in it now. ...also, can you upload a picture and update a database with the same form, but still maintain the ability to update one or the other without problems?...thanks for any direction you can point me in!love,jason

[shiftJIS]

While it's not impossible to store image data in a database, people tend not to. I think the reason is that fetching the image back then requires connecting to the database, fetching out binary data, and then formatting it with the right headers so that browsers will treat it as an image. Thus, you'd need a .php file as a wrapper, and every time someone looks at the image, you'll be calling mysql and spending a lot of processing time when you could just have the image on a file that the server would easily spit out.What usually happens is that people take uploaded images and move them to some specific folder, put some name on them, and sync this information up with a database (putting in tags/information etc, but especially the filename that it was saved under). So, assuming you amass a whole bunch of images, you can make a query for specific image, and use the filename provided in the database to retrieve the actual image. You can surely imagine that having a field of image data (which could be 1mb or over) slows down queries of the database.As for the unique names, I've seen methods that used md5 hashes. I personally just use the unix time that the file was uploaded (then the field will serve a double function). If you're programming a huge site like flickr where obviously people will be uploading things at the same time, then I'm sure you have some full-proof way of making sure images are unique (perhaps every user has their own folder? I'm sure they have software engineers with more creativity than me working for them). I'm sure the others in this forum have ideas/tricks of their own also.As for updating both separately or together, it's all up to your code. The database makes no restrictions on what you do with the fileserver and vice-versa.

[justsomeguy]

As far as storing images in the database, I did one experiment with that and decided it was too slow for general use. Not only does it put a pretty big strain on the database if you need to pull out 5 or 10 images for a page, in addition to the other content, but it takes the PHP image script a little while to put the image together. And, browsers tend not to cache the images. You can see an example here, all of these images are between 2-5kb but it takes a little while to display them, or at least longer then it would if they were static files.

[MinusMyThoughts]

well, for my purposes, i won't be using many images. so if i just place my uploaded images in the /images folder named, say, pic1 through pic9, i'll probably be alright......just a quick question, though: if i have an image loaded called pic1, and i upload another one that will be replacing pic1, will i get an error, or will i need extra code to overwrite the file?...thanks!love,jason

[aspnetguy]

it should just over-write it quietly