On Thu, Aug 6, 2009 at 5:02 PM, Michael A. Peters<mpeters@xxxxxxx> wrote: > 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. > This is a very old, sometimes hotly debated question. Google around a bit and you'll find lots of discussion on the pros and cons of each approach. It usually comes down to a design decision (or developer preference) trying to balance the benefits from both approaches. Sometimes you'll even find hybrid solutions that try to get the best of both worlds. Sometime, you don't have much of choice, though. For instance, some of the sites I manage are split, with the administrative interface on a private intranet hosted on a server that is almost totally isolated from the public-facing web servers that use the same information. In this case, network policy prohibits us from mapping a common location that both machines could access. Since the network policy is unlikely to change, and since both systems have access to the database, that is the easiest place store images and/or documents that need to be accessible to both. Andrew -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
