Topic: An image repository.. or not?? need advice here (Page 1 of 1)

Ok I'm on to the part of the project where now I need to work on allowing users to upload their photos. I have like a couple of options to work on but can't decide which would be easier to code / and less intensive. Like I could add to the tables i.e. users, company tables an extra Blob field and treat each picture as part of the tuple in question.

However theres just one little downfall is that upon getting backups wouldn't this result in a number of really large tables?

The other option is to make an image repository i.e. one table containing the images and the detaisl on which element this image is for. In this way I have just one large table with the images. However theres an issue in mind with respect to this and that is like all elements with pictures have just one photo attached to them.. [I guess]...


Oooor theres the other option of just maintaining a folder and dumping all my images there.. but this seems to dirty or too simple that it scares me.. any ideas guys on this?

I'd go for the last option : a folder for the images and a table of indexes/names. If possible, I'd even rename the images by their UID in the DB to ease the pairing of the actual file and the entries in the DB.

storing your images in the database is a sure fire way (at least on the regular mysql shared hosting setups) to get abysmal performance (and I've always wanted to use that word ).

TP True, storing large blurbs of binary of data is sub-optimal.

You guys have a point - besides its pretty pointless to use it for just showing single pictures for each element. I'm sticking for the folder option, oh and thanks for adding a new word to my vocabulary Tyberius 'abysmal' - that sure required a quick trip to the dictionary.