WYSIWYG Editor Image Browser Development

To all who may be interested:

In designing my own content management system, I've come across a bit of a development conundrum: how should I store the images which the user uploads? From my vantage point, there exists three possibilities: storing the files in the web's filesystem and then allowing the user to search through the physical directories for the image, uploading the files directly into the database and allowing the user to select an image from there, or a hybrid of the two methods where I store the physical image on the filesystem, but create an entry in the database which references the file and stores information about it.

Which method do you think works best? Each comes with its own pro's and con's, and I'm unsure which works best. What are your thoughts?

Thank you all for your time and have a good one.

MS SQL 7 and later allows you to store an image (binary) in the database.

I used the combination approach to develop an online journal system. I created a directory for each user (ie. c:\Inetpub\Images\username\) using the file system object, and allowed the user to upload each image to their own directory. The url for each image was stored in the database. The only reason I did this was that I wanted the user to be able to use a variety of databases, from Access to SQL to mySQL, and not all handle graphics well.

loading images as blobs directly into the database, is a bad idea,

You are best to upload an image to a directory - but dont forget to give it a new name, otherwise another user might upload an image with the same name.

then store the name of the image/file in a table.

It works a lot faster than storing blobs.

Just my thoughts

Coyote: why do you say that loading images into a database is a bad idea?? its actually a good idea! I have tested on my local server the speed differences between a blobed image and one from a dir. the result??

On average, the database was quicker retreiving the blobed image then the one from the directory! So infact its better to store your images in a database, also if you move server, its alot easier to move your data from a database, to another database, then from one dir to another dir.

I always believed that it was better not store images in a datbabase as well, I must admit that I've never actaully done any testing.
Ben can you give us more information on the testing you've done. What database? How many images did you have in the database and how big was the database?

Ben,

How do you backup the database with blobs? It seems like it's much faster to download a directory and then re-upload it to a new server. (Never done it...just what I think )

-Corbb

Hi,

I have used both methods to store images/pdfs/zips.

The main problem you have with storing the blobs directly in the database is speed. Which you may not notice when you have 10 or 20, but when your table expnds and you have maybe 200 photos - you will notice speed problems.

I have also learnt that the Tables seem to corrupt easier when storing lots of blobs.

Thats why I now choose to store only the location of the image.

If you havent done it before then it may be a pain the first time, but once you have it as a class, it will make life much easier.

as Web Guy mentions, backing up a database full of blobs also opens problems. Such as PHPMyAdmin generating such a large stucture complete with data. On most servers there is a limit to how large this can be.

If however you are only storing a few images - say 10 small 8k or something like that.... then you may not notice a difference. But you do limit your code by doing that.

I am no expert in PHP or MySQL, I am just explaining what I have learnt. If anybody has any other views on this, I would love to hear them.

Oh and Ive just thought.....


storing the location of the image also opens up the possibility of storing images remotely. Thus controling your own bandwidth.

the database i used was mysql, on my localhost. I tryed it with 4 groups of images, <1KB, 1KB - 10KB, 10KB - 150KB, 150KB+

what I found was that the first 3 groups were noticably faster, about 0.004, on average.

150KB+ was a let down, with it being a bit slower, 0.001 on average