For any web application uploading an image is comman task. But what is the comman way to manage the uploaded files?
Generally what we do is place the uploaded file on specific folder and store the name of the image or some times path to image in VARCHAR field of the database table.
But this article is to cover the concept to store the image in mysql database. Later on we will discuss how to show the stored image from database to the web page.
For this article I am assuming that you are somewhat familiar with the PHP basic file upload process. So without explaining that process I will directly go with the main part of this article.
I will directly show you the code which insert the image into MySQL database. But before moving to that code let me explain the datatype which we are going to use for the image. We will use BLOB datatype of MySQL.
BLOB in MySQL
BLOB stands for Binary Large Object. This types used to store the Large Binary Objects. We can have 4 type of this Datatype.
- TINYBLOB
- BLOB
- MEDIUMBLOB
- LONGBLOB
Store Image in MySQL Database
Now considering you have pressed the upload button for the image and you are at code block at which you want to save image in the database table. Have a look at the code block for the same.
[cc lang=”php”]
// Check if we have file uploaded or not.
if(is_uploaded_file($_FILES[“to_upload”][“tmp_name”]))
{
// Instead of moving file to any specific location
// We will read the binary content of the uploaded image
$image_content = file_get_contents($_FILES[“to_upload”][“tmp_name”]);
$image_content = base64_encode($image_content);
// $image_content can be stored in the MySQL table with BLOB datatype
}
[/cc]
This [code]$image_content[/code] variable can be stored in MySQL table in the fields with datatype BLOB. In next post we will see how to show this stored binary data as an image in webpage.
Subscribe to RSS Feed to keep updated with the new upcoming posts.
You’re explaining how to store them in the DataBase… but why would one want to do that in the first place? An image is quite large, so the connection handling this is going to need more bandwith to deliver you the image.
The benefits, on the other hand, aren’t clear. If you store the path, the only downside from what I see is that when you want to backup your website data you have to remember to make a copy of the uploaded images too.
Apart from that, wouldn’t BLOB types handle correctly the first input, the output of “file_get_contents”? Why is it needed for the content to be encoded in base64? It’s an extra operation and increases the size of the image.
Won’t this significally slow down your website if you have a large database of images?
There are not any major benefits over other methods but i this is the alternative way. I strictly have to follow this methods as per client’s request. :)
[…] this article is to cover the concept to store the image in mysql database Database Read the original post on DZone… […]
[…] by Avinash on Jan 22, 2012 in Code Snippet, PHP | 0 comments In earlier article we have check to store the image in database using the BLOB datatype. In this article we will check for how to display the images which are […]
In my opinion, this is a bad solution. This will increase your data-storage, slowdown your application and under some circumstances you will get problems by creating a backup (to large db).
If you work with a MASTER/SLAVE config… forget it!
can u tell me code for save file path in database instead of directly save the file in to database while upload a file?why means when u save directly it occupie large memory in database and also when take dump of database u want import u r not able to import dude to high memory of dump . so i want code for
how o save path of uploaded content
Thank you but i think i will be needing alot of help out here…regarding the viewing of the image..
You can have a look at this for the same: http://localhost/xpertdev/2012/01/view-image-stored-in-database-php/
@Lumbendil, this is sometimes required for maintaining transactional coherence. Say a process deletes a record from the database but there is a system failure before the actual file is removed. You end up with more files than what you have in the database. This in turn causes filename conflicts if those are generated by your app based on what’s in the db. A reverse situation is no less scary – you start serving non-existent files. Of course, all this can be handled but it takes additional effort.
Now, for large systems there are obviously dedicated, enterprise-grade solutions available with various kinds of bells and whistles. The thing is these are either expensive or require major setup effort. With low-traffic or low-support apps moving everything onto the db instead of coding workarounds might not be such a bad idea. If the images are sane size-wise you know you won’t suffocate the caches, the performance impact is negligible (even 200% of 0.2s is unnoticeable to the end-user) while having everything in one place, where db itself handles concurrency, transactional safety, and backups can be a major relief.