RE: image uploads

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Don't mistake client side cache with FS / WebServer cache.
Also, take into consideration that getting an image from FS is much 
More efficient than from MySQL so why go there?

As for order, that's really not a problem as you can build a simple
Directory hierarchy such as : /home/MySite/images/b/be/berber.gif

We handle more than 20M images and files with no problem this way.

berber

-----Original Message-----
From: tedd [mailto:tedd@xxxxxxxxxxxx] 
Sent: Wednesday, February 01, 2006 4:23 PM
To: php-general@xxxxxxxxxxxxx
Cc: Kevin Waterson
Subject: Re:  image uploads

Hi gang:

I don't mean to offend anyone, but I'm going to side with Keith Waterson
about storing images in a dB rather than in a file system. 
My reasons are pretty simple.

First, an image is nothing more than a large of string text -- sure it's
voluminous, but there's no difference how it is stored -- either in a dB or
fs, it's still all just 1's and 0's stored on a hard drive.

Second, when you search MySQL, you're not searching blobs (hopefully)
-- instead you are searching the index. What is attached to the index has NO
effect on a search.

Third, MySQL search routines are simply binary-trees. The indexes are simply
pointers to the data stored on a hard drive -- no more, no less than placing
url's in a dB and using those as "pointers" to the image stored on a file
system -- which may actually take more time resolve.

Forth, with respect to the argument of caching the images, your browser
doesn't know how images are provided. The image is coming from a simple
<img> tag or a header file and the browser simply looks at what's there and
compares it with what it has and loads the image accordingly.

If you want to store your images in a file system, then that's fine
-- but as the number of those images climb, you're going to need a way to
organize and handle those images -- and that sounds like a problem that a dB
can solve.

I can understand image storage being something somewhat problematic. 
It's not abundantly clear what is actually going on when you store an image.
People have impressions that BLOBs are huge attachments that "slow" down dB
operations because of their size and when you delete one, there's a huge
hole left in your dB. But, those are just unfounded fears, which IMO are
reenforced by people's problematic experiences in trying to get things to
work.

For example, I have read numerous times in the archives and on the net that
there is no way to consolidate a MySQL dB after you have deletions. The
holes in your dB will remain. But that's not true, while it may not be the
best to consolidate a table, it can be done with a single line of code.

It's claims like this that add to the confusion of how you can use MySQL and
thus create the illusion that you shouldn't use MySQL to store images. But,
until someone provides me concrete evidence that MySQL can't handle images
as well, or better than a file system, then I'll consider the claim to be an
urban myth based upon people not really understanding MySQL.

tedd
-- 
----------------------------------------------------------------------------
----
http://sperling.com/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux