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).
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php