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.
Bullshit. there are multiple tools for copying files from host to host, including ftp, scp, sftp, rsync, nfs, etc. Planning ahead, is a better way to avoid breaking links than using MySQL to store your images. 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.
Not it's not. If you have a single mysql server then this situation can be replicated by having a single image server. If you have a clustered mysql system, then this can be replicated using something like rsync 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.
I notice you've misspelt the most important word there. He says the lookup _MAY_ become slow. This behavour is dependent on the filesystem you are using. You will encounter this problem with ext3 if you have too many files in the same dir. You're less likely to encounter it with reiser. This comes down to the competance of the administrator. An incompetantly setup mysql table ( without indexes ) would have the same problem. 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.
For a small enough site you can encode all your images inside a bigger image using stenography. Bad solutions generally work for small enough sites. Failing to plan for the growth of your site is however a bad idea. 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?
We're not talking about generic binary files. We're talking about images images that people upload. Using blobs to store small (order of kbs) of transient data is fine. I just don't want to end up maintaining systems that store images in the sql db. ---
At 1:53 AM +1000 5/11/06, Peter Hoskin wrote: >So, if ASCII and Binary are both codesets... which does SQL use to store >its data? Is ASCII stored differently than binary on a hard drive? From my limited experience in using a hex editor, the data all looks the same to me. If it wasn't for my hex editor, I would be looking at 1's and 0's, right? After all, isn't an image in a file system stored on a hard drive the exact same fashion as an image stored on a hard drive via mySQL? The only difference I can see is in overhead -- but then again, I may be a Moron or an Idiot like Rory Browne suggests. Perhaps someone might enlighten me as to why mySQL is not suited to store images -- and prove it. And for goodness sake NO, Google is NOT always right -- it's only a collection of everyone's view. When did Google replace valid research? I can see tomorrow's mother's saying to their children "If Google jumped off a bridge, would you do it?" Let's get real about what Google can offer. Specificity is inversely proportional to the number of people voicing an opinion. I would guess that even Morons and Idiots know that. tedd Typical disclaimers apply -- I did not mean to offend anyone nor to imply that anyone is an Idiot or a Moron. Your mileage may vary. No warranties expressed or implied. This is not a solicitation for an investment opportunity. Consult you doctor before applying. No hable inglés. -- -------------------------------------------------------------------------------- http://sperling.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
