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
