Re: Re: Upload File (binary files?)

tedd wrote:

At 1:02 AM +1000 5/11/06, Peter Hoskin wrote:

Despite common belief, SQL is not suited to the storage of binary files. SQL is based on ASCII. Store your files on the filesystem, not SQL.

How is it not suited? I stopped using mySQL to store images because of browser refresh problems, but other than that -- I didn't find any major problems with using it. Plus, moving images from one system to another was much easier because you just moved the dB and you don't have to worry about the file system and breaking links. In addition, if you are using multiple hosts, who require the same images, then using mySQL is far superior than trying to keep all the images in different file systems synchronized. Furthermore, according to Paul DuBois (author of MySQL Cookbook, great book btw) who says "If you store images on the file system, directory look-up my become slow" in his comparing file system to mySQL for image storage. Additionally, transactional behavior is more difficult with a file system than it is with mySQL. Granted, if you use mySQL for storing images, then you bloat the tables and approach your system limits faster than using a file system. But for a limited amount of images, there isn't any real problems. And granted, pulling images from mySQL to be used in web sites are slightly slower and present refresh differences between some browsers, but that's certainly not a reason to say that mySQL is categorically not suited for the storage of binary files -- like with everything else, there are trade-offs. Do you not see that?

I think you make interesting points Tedd, it's given me stuff to think about anyway. leveraging a Db for image storage can have advantages but implementing it correctly takes a stack more knowledge and more work to do it correctly, therefore the recommendation for those starting out in php should, I feel, remain 'use the filesystem' - if only because understanding and using the filesystem properly is one of the foundations of the craft. no? with regard to the refresh issues I believe this can be dealt with by outputting correct last-modified headers with the image data (which can also be stored in the DB ;-) with regard to increasing speed: what I often end up doing, mostly because I allow dynamic resizing of images (i.e. the thumbnail and the 'large' image come from a single stored source) is to use a memory based cache where previously outputted images are stored for as long as possible (i.e. until the source changes or the server is restarted or the cache is full or whatever).