This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
What is the best way to store a series of images in MySQL?
This is the first website that I built for a friend a few months ago:
http://www.jpsinghphotography.co.uk
I want to rebuild it as my first PHP/MySQL project, but I had a couple of questions regarding how to structure the database.
1) Is it best to put the actual image files in the database using BLOB data types; or store the file names and use these to look up the images from another folder on the server?
2) I'm new to SQL and I'd initially imagined a seperate table for each gallery I want to create. In what ways is one table sorted by category better?
Thanks for any and all advice
Welcome to stackoverflow.
You can put image data in MySQL, but it's usually better to put them as files. That make them easier to cache and thumbnail, otherwise you have to do them yourself.
One table sorted by category would allow you more flexibility in category names and make it easier to move images between categories as well as get information from multiple categories such as image count of each category.
I would stick to providing a reference ie. the file name in the MySQL table. Putting the images in the table as BLOBs would mean you're now maintaining two copies of your pics. If you're primary application is to store history, this makes sense, but otherwise, a simple reference to the original is probably better.
A secondary issue may be storage space: you'd obviously be dealing with some very large tables if you BLOB the pictures. That may or may not be a problem.
As others posted, creating multiple tables for each gallery is a definite no-no and against the whole philosophy of using a relational database. Simple add a column to the pictures table that holds the gallery id and make it part of the unique key. You may also want a separate gallery table too, to be more 'normalized' about it.
Related
Thanks for jumping by!
I'm building a PHP script to manage employees, and I would like to get your help in deciding which good way do you use to implement multiple size for profile picture thumbnail.
The sizes may change (would like to keep it dynamic), thus, I can't set a specific column name for each thumbnail size.
I assume there are few options:
I can create a database table for each profile picture, there I will save the thumbnail path and "bind" to the user id with a foreign key, then I will be able to get all profile pictures and sort them based on my needs.
I can generate a thumbmail and save its path in the "users" table in a special column called "thumb_path" or something similar - in the same way I can store instead json of the profile picture paths (while the key represent the thumbnail size).
But both seems to be a bit wierd for me, and I can't clearly thing about another way to implement in efficiently.
Will be happy to get your kind help!
Marco.
I suggest to create one table for the thumbnails, with a reference to the user_id, the thumb path and the info about the size. You can have multiple rows for a user.
Hope this will help you.
This question already has answers here:
Storing Images in DB - Yea or Nay?
(56 answers)
Closed 9 years ago.
I want to create an image gallery and obviously, it must have images in it.
Somehow, I've been wondering about what's better between storing the images in a directory and retrieve them one by one or store them in the database as a BLOB data?
Thank you people! Cheers!
I am willing to learn either of the methods so please enlighten me.
This question has been debated for many years. Advocates will make strong cases for each. Neither side as ever been definitively proven to be right in all cases.
Both methods break down when the number of images that you need to warehouse gets very large. Both databases and file systems have become better in the years since I bench marked both options against each other. At that time, you could fix the performance hit on the "file system" option by creating a hierarch of directories instead of putting them all in one directory. By now, file systems may have been optimized so that they don't choke when the number of directory entries gets large.
This is truly a "your mileage may vary" situation. Factors will include what file system will you use vs. what database engine will you use, how many images, what average size? Will you be "tagging" the images in the database as well as storing them?
Typically, you have to just try all the options until you find something that works in your configuration.
Definitely stress test it. If you think you need to store one million images, don't test with five and assume that it will scale.
Test it with at least a million images, if not with two or five million.
That said, if you only need to store 1,000 images (or less) maybe even 10k or less and if you need to index the images by attributes like date, location, subject matter, etc. then at the risk of offending many well meaning people, I am going to recommend storing the image as a blob in the database. The convenience of using the database to join the image to the meta data will outweigh anyone's performance concerns at that scale. When you store the metadata in a database with a pointer to a file in the file system, it is too easy for things to get out of sync. The file gets moved, renamed, deleted etc; your database wont know and now your system is broken.
Using a database will insure the integrity of your data, including the images for you.
First you will need to upload file in any predefined folder and than you can store name of that file in your database(with is varchar data type).
And when you will fetch those records, use that name to recreating image path wherever application required.
I'm looking at setting a site up with a large number of searchable images, organised by keywords, tags etc. I'm planning to get the image information from the IPTC data. The images will be uploaded by FTP then added into a database. My question is this:
Is there any advantage to storing the IPTC data in the database record for each image or just getting it from the file as and when it's needed?
My gut feeling is that it would be more efficient and easier to work with to have it all in the database but I'd like to make sure before I start to build anything.
I'd certainly put the data into database in some form. You can then ensure that it is indexed and is much faster to search. To get maximum benefit, you would need to preprocess the data into a format that is easy for the database to search. EG keywords should be stored individualy or coded as a many to many relationship (picture_ref, keyword_ref pairs) between the picture and a central list of keywords.
What's the advantage of storing images or the path to images in a database compared to directly linking to the images from your script?
Edit: Isn't hardcoding the urls in the script also faster since you don't have to do a database lookup for every image in your webpage?
Because you can dynamically alter the paths later, or be able to manipulate them, otherwise your 'script' would have to be updated EVERYWHERE (imagine your script(s) grow to large sizes).
Database makes management of data easier, and eliminates hard coding in your example in scripts.
It is never good to hard-code something.
EDIT
I just noticed you said 'storing image' I wouldn't store images in the DB, safe them for the files system and reference with the path like you stated in your question.
It's impossible to answer to such a vague question.
What images you're talking about? Design images? photo gallery images? avatar images? It's all different cases each with own solution. Storing image names in the database will do any good for only one case out of these three, as it would be easier to group, arrange and interlink images in the gallery. While for the other cases there is not a single reason to store image names in the database.
Anyway, it's all applicable to the image names only. As there are not a single reason to store any URL or path beside image name. Url should be computational based on some rules, not hardcoded one.
I do not typically do this with basic site images, but the definite advantage can be for scalability purposes. If the image is going to show up in different scripts, they can all reference to the db, thus giving you the ability to only have to change the url in one place.
I have 500k unique images in my folder/directory. I want call it by name and all names are stored in Mysql database. but I heard that images can be stored in a database. So my question is which is more fastest option to display image faster. do I need to store in mySQl or can I keep same method which I am following?
If I need to store in mySQL then how do I create a table for it, and how do I store all these images?
This has been answered quite a few times. But you haven't talked about what type of application that you are building, if you are building a web application then storing the images on the file system has advantages re: caching.
Storing Images In Filesystem As Files Or In BLOB Database Field As Binaries
Storing Images in DB - Yea or Nay?
It's easy enough to store the images in a table, I would definitely avoid it though if your images are quite large.
I do not think 500k entries in a single directory will go over very well: How many files can I put in a directory?
Once upon a time, Linux ext3 started running slowly for very simple operations once a directory accumulated around 2000 files. (O(N) sorts of slowly!) After the htree patches were merged, large directory performance improved drastically, but I'd still recommend partitioning your image store based on some very easy criteria. (Squid web cache, for example, creates directory trees like 01/, 02/, and places files based on the first two characters in the filename.)
Do not store so many data in a db like mysql especially if you are not so familiar like you sound. Keep the images on the fs
I have 500k unique images in my
folder/directory. I want call it by
name and all names are stored in Mysql
database. but I heard that images can
be store in database. so my question
is which is more fastest option to
display image faster.
You should use the file system. Storing in database is not going to work very well. You should read Facebook Photo Storage Architecture to learn how facebook does it. They have the most photos in the world.
Haystack file storage:
Also interesting:
http://www.fredberinger.com/high-performance-at-massive-scale-lessons-learned-at-facebook/
Storing images into the database (in a blob datatype) in much more inefficient than keep those images stored on the file system.
BTW here is explained how to insert binary data into a mysql table
If you have Redis, you could put all the images in memory, that would be the quickest way