Please do not expand this. Storing images in a database instead of links to the images is bad style. Some problems.
a) People start to use <img src="sendimage.php?image=myimage">
Ok, say you have one index.php which generated the above HTML output. If the user opens the index.php in its browser, the script sendimage.php will be called. That gives:
1 web server process for the image.php
n x 1 web server process for the sendimage.php
And very likely also:
1 database connection for the image.php
n x 1 database connection for the sendimage.php
With n beeing the number of images on the page index.php. With other words, this approach requires n-times more processing than an index.php which reads the _path_ to the image from the database and prints out <img src="/path/to/myimage.gif">. If you want to slow down your web server to 1/n of its performance, great, go on and kill your web host.
b) <img src="sendimage.php?image=myimage"> prevents the usage of specialized, fast web servers
Apache is a slow, large monster web server. Many slim and fast web servers exists which can serve images a way faster. Use extra web servers for media files, e.g. images and use <img src="
http://myimageserver.com/path/to/myimage.gif">. Use the fat and slow Apache only for serving the complex pages which require complex web server software
c) Databases are not optimized for BLOBs
In almost every database, BLOB storage is not very much optimized. That's because BLOBs are too large to be stored on the same database page as the other columns of a row. This leads almost always to extra fetch operations and more hazzles with the database cache population etc. - simply avoid reading/writing BLOBs frequently. It's extremly difficult to optimize the physical storage for BLOBs in general. MySQL is no exception to this.
d) max_allowed_packet
People always run into this limit, sooner or later. OK, only a configuration issue and the protocol limit of 1GB is not that much of an issue.
But there is another problem AFAIK: no chunked reading, the client has to read all bytes at once. If the BLOB is 10MB the client has to allocate a 10MB buffer. It cannot fetch 10 smaller 1 MB chunks from the server. The client will allocate large buffers which can become an issue if your BLOBs become large.
Conclusion: storing images in the database is very likely to slow down your PHP application and increase server load dramatically. Using paths to images and storing them inside the database is usually much better.
... and one final word about this incredible inefficient 1), 2), 3) that people requests:
1) inefficient storage inside the DB: extra access operations, likelyhood of bad cache usage figures increases
2, 3) extra load on the file system, extra CPU cycles, extra load on the database - what is so hot about getting some cakes from the supermarket, wrapping them out, wrapping them in again, putting them into the shelf, fetching them from the shelf, wrapping them out again to eat some vs. buying, storing, eating.
Ulf