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