I did mean, if u want to store a image in the database it would be a blob
field, a blob field is a indifidual file in the database anyway,
I mean if i would do that type of design i would store the path to the image
file in the database and give the browser the path to it for download.
however there are some reasonable reasons to store a image in the database.
1. if u have no access to write files to the disk this is the case in most free
hosting services they give u php and mysql and thats it
2. if u want some access control to the image, e.g. login controlled. server
admins dont like u playing arround with the htaccess file
3. its easy in those and other cases
4. image directores are public, and apear in search engines
Von: Michael A. Peters <mpet...@mac.com>
An: Ralph Deffke <ralph_def...@yahoo.de>
Gesendet: Donnerstag, den 6. August 2009, 23:02:55 Uhr
Betreff: Re: [PHP] Displaying user data and picture
Ralph Deffke wrote:
> and a blob field in mysql is
> the right thing, however u have to have a little php scrip, however with a
> .png extention to get the browser displaying the picture.
What is the advantage to storing an image in the database opposed to as a flat
It seems to me it would require an extra database call, which could be cached
but the cache would then grow to a monster size for sites with a lot of images.
Flat file involves a filesystem call, the disk arm has to move, but files on
the server that have recently been read are still in the servers memory cache
(at least with Linux) and do not require disk arm movement. Database calls that
are not cached also require disk arm movement.
I ask not to criticize the procedure, but to find out if it is really worth it.
My web app does not store images in the web root so php already is invoked to
open the file, read it, sometimes manipulate it (add a server side watermark),
and then send it. It reads the data from flat file.
I don't have any data blobs in my database - which makes incremental backups
easier - I use rsync for files and do a nightly mysql dump. Except for the
first of the month, the diff of that nights backup compared to first of month
is saved to flat file for rsync. Binary blobs in the database would likely mean
I have to change my backup protocol, but if it really is advantageous, I'd do
I do store information about the images in the database, but that's rather
small and easily cached by APC w/o needing to allocate too much memory to APC.
Add data blobs and the cache would explode in size.