I am working on a online shopping website, it will have product images also. I have confusion regarding were i should store images. If I store these images in the database image url must be kept into the database and if i store image in blob format i have to decode it before using in php. Can anyone tell which one will be better choice?
I think the best solution is to keep the Database clean of any images. Below are number of reasons -
Database will soon start to grow
File system is good for storing files
You have put extra effort to decode them in PHP(Resource overhead)
Many databases I have studied keep the images in the File System (WordPress source)
Hope it helps
Related
I am working on a small social media project and one of the things I want todo is allow users to upload an image. I originally was thinking about uploading the actual file to a image directory and saving the files name in the database to call it later.
However there is a limit to how many files I can have in a directory, and file size can be an issue.
So instead of going this route I looked into simply saving the image data using php's file_get_contents() function to the database as a BLOB datatype and then writing another script that renders an image from the image data.
This kinda seems like a no-brainer and a better route since image data would be relatively small in size.
I am worried though because it seems like its too convenient. Is there a reason why I shouldn't do this? I mean a real viable reason? Is something gonna bite me in the ass later because I am going this route?
I hope this was the right place to post this question. Thanks in advance.
Be aware that serving images from a database is usually much, much much slower than serving them from disk. It'll start a PHP process, create the database connection, query the database, transfer it and then pushing out via PHP which would be non-cacheable.
There are some complexities to storing images in a database but it does allow for easier sorting and deleting, and you can perform additional checks if security is of concern, and logging if that is of interest.
See https://stackoverflow.com/a/1638348/5509627 for implementation.
If disk space is only concern you may consider storing the images in AWS S3 or similar.
I'm creating a blog with a featured image on each post. I have a dilemma, I'm unsure what to do with my image data...
Should I insert image data into my MYSQL database using BLOB?
Or should I just create an uploader which makes a directory into the users images folder and upload the photo that way...then just reference it directly in the image field when adding a Blog Post?
Is there a standardised way?
Kind regards,
adam
Upload the files to your server and save the location of the file in your database. Less strain on your DB and your HTTP daemon is better at serving images than MySQL.
The general approach is not to store files in DB, unless you understand why do you need it to be stored there. So, since you are not sure, it's much simplier storing them in upload folder.
But, just in case you decide you need storing files (no matter images or some other) in DB, you have to declare BLOB field and then save it using some BLOB-supporting DB mechanism. 'PHP's MySQLi extension: Storing and retrieving blobs' is a good example of how it can be made
You should store images in folder. Click on below link from where you can get idea how to crop different-different size images and store images name in to database table:
How can I upload images in a normal insert form (MySql)? after upload the image should have three versions of different sizes and different names
convert the image data to base64. This can be done within PHP:
<?
$image=file_get_contents("image.png");
$image=base64_encode($image);
?>
Storing images in a DB is a good idea for secure images.
Always store images, music files etc in system files on disk, and then store the urls to them in the database. That will make it
1) faster
2) easier to configure security settings
3) better in any ways I can imagine
Disadvantage
If file system is corrupted you will have hard time recovering.
You can also use third party Image hosting sites too, you can use Amazon S3 or Mosso Cloud Files.
Problem with file system is it is difficult to scale.
Facebook uses cassandra to store images.
Since it is blog you can store images in filesystem.
Both are valid approaches.
They have different advantages/disadvantages.
Storing it in the database means you need to add extra code to change the image to a representation which will fit inside a INSERT/UPDATE statement (base64 is one approach, and requires equivalent decode, but you could just use mysql_real_escape_string()). Although you can't query the image directly (other than finding exact matches) it may reduce the number of seek and I/O operations required to retrieve the data compared with looking up the path in the database then retrieving the file.
It's also a lot simpler to set up replication of a database compared with setting up replication of the database AND the filesystem if you run on multiple nodes. And there's the issue og keeping filesystem and database backups synchronized.
OTOH, using a filesystem makes your data tables much smaller, and therefore faster to retrieve records from.
which makes a directory into the users images folder
You certainly don't want to allow users to upload content directly into your webserver's document tree - regardless of which route you take, the data should be stored in a location not directly accessible by the webserver but accessible by your code.
I'm using SF1.4 and Propel and I'm having a slight problem with trying to save images to a field in my database.
Does anyone have a small example that I could work from?
Keep your images in a filesystem. Is there a special reason to store images in a db ?
You can store only generated filename. Because storing blobs in mysql will freeze your application. Give this task to a webserver.
I've had a bad experience saving images as blobs. Specially when you have to change your database engine. But if you still want to go that way. I found this useful http://oldforum.symfony-project.org/index.php/t/25699/ though its based on Doctrine.
which is a better place to upload images to? A database or in the web directory? And why?
You should only store images in your database if you have a specific need to, like security, or like an absolute to-die-for need to keep all custom data in a database.
Other than that, getting large files into databases usually isn't worth the trouble. Storing and retrieving the file get that much more complicated to implement, and database updates/upgrades/conversions have that many more things that can go wrong.
I don't see that there is an advantage storing images in a database. There is certainly no inherent security in this. Files are for the filesystem so store your images in there.
I don't think you can "upload" an image to a database. You can store the image's string value in the database and stream it via "header("Content-Type")" later on. That saves space in your web server, but obviously takes space on your database.
If I were you, I'd upload to a web directory, that way you have the image for a regular URL request later on. If you don't have it in a regular directory, you'll have to connect to the database every time the image is requested, and stream it then.
Well It depends on your requirement.
If you are considering security as a major issue then definitely you should store it in db other wise nothing will leads you to store images in db.
Also retieving images from database is quite complicated as in database images are stored as binary data. So if you have specific need then only store images in database other wise storing images in directory would be fine.
As you can see there are many reasons why to use/why not to use the database for image storage. Personally I prefer not to use the database for storage of files (images, documents etc), except when I'm ordered to store them.
-Sometimes you're tired and screw up a query, something like "SELECT * FROM images", this will kill the server if there are too many images with huge size (2MB and more) in the database.
-The security issue: you can still save the files in the disk and still be secure, how? Well save the files outside the web directory, whenever the file is requested read the file and give it to the user.
-If by any chance you are using MySQL: if your database has got to big (say 2-3 GB), and you are using a shared hosting, well good luck making that backup or trying to restore that image database.
It's just my point of view
The best way to store images into MySQL is by storing the image location as a character string.
If you need to manipulate the image, then, the best way is to copy the image as a binary.
How one can store images into binary form and how we can retrieve them back? I don’t know anything about this technique. Please tell me how we can do this.
Don't store images in the database. Store them in the filesystem, then store their relative paths in the database.
I've written some blogs on this (and have some data from SQL Server)
http://www.atalasoft.com/cs/blogs/loufranco/archive/2007/12/03/images-in-databases-part-i-what-to-store.aspx
http://www.atalasoft.com/cs/blogs/loufranco/archive/2007/12/04/images-in-databases-part-ii-web-images-are-random-access.aspx
http://www.atalasoft.com/cs/blogs/loufranco/archive/2009/10/26/more-on-images-in-databases.aspx
Basically,
Small images are ok to put in a blob
Large images are much better to put on the filesystem
Images in a blob are much easier to manage (transactions, backup, simpler code, access control)
Images on the filesystem will perform much better
Think about pulling some meta-data out of the image and storing in separate columns for filtering and sorting purposes.
Almost every professional enterprise system that needs to deal with a lot of large blobs has some way of putting them on the filesystem. The latest SQL Server even has a field type that will do it automatically (and then it's as easy to program and manage as a blob)
You can use the BLOB data type. Although I agree with #Ignacio Vazquez-Abrams, there are times where storing the image in the DB is best. I have done so in past with great results. As long as the files are not large then this is a good solution.