0

Possible Duplicate:
MySQL - storing images in a database??

I'm working on a profile system for my webpage, However I was wondering what the best way to store images are.

The first method I have read about is using BLOB in mysql. The second would be how I planned to do it in the first place, First i would get the image from a upload script, then giving the picture a id (md5) then renaming and move the picture to a folder named "md5".jpg

I was wondering what the best option is.

Community
  • 1
  • 1
aaaa
  • 157
  • 2
  • 13
  • 8
    Sigh...this has been asked and answered about 50 kajillion gazillion times on this site... – Marc B Apr 20 '11 at 16:13
  • I've tried searching for this, Perhaps you could link me too a previous question? – aaaa Apr 20 '11 at 16:16
  • what query you tried to search for? – Your Common Sense Apr 20 '11 at 16:17
  • 1
    http://stackoverflow.com/questions/1257488/mysql-storing-images-in-a-database – Marc B Apr 20 '11 at 16:17
  • http://stackoverflow.com/questions/1257488/mysql-storing-images-in-a-database, which links to the many dupes of this question (and which I found staring at me from the "Related" list in the sidebar. As for searching, did you try "images database filesystem". You should. :-) – Greg Apr 20 '11 at 16:19
  • 3
    You know, it's even no need to bother with search. I tried to start another question with your title and got a dozen suggestions immediately. Didn't you notice it? – Your Common Sense Apr 20 '11 at 16:21
  • My titles been changed multiply times since I posted this, I was searching for the wrong keywords I guess... – aaaa Apr 20 '11 at 17:14

7 Answers7

3

I have seen this question pop up before, and the generally accepted answer is to store your images in a folder, and then store the URL in the database. I think it is technically possible to store an image in a database using a BLOB, but from the documentation and consensus that I've read online, this is not a ideal scenario.

Databases tend to work well with Numbers, Strings and data files.

Here are some links on this site for the question you are asking:

Storing images on a database

Storing Images in DB - Yea or Nay?

Community
  • 1
  • 1
hypervisor666
  • 1,275
  • 1
  • 9
  • 17
1

From Choosing data type for MySQL?

MySQL is incapable of working with any data that is larger than max_allowed_packet (default: 1M) in size, unless you construct complicated and memory intense workarounds at the server side. This further restricts what can be done with TEXT/BLOB-like types, and generally makes the LARGETEXT/LARGEBLOB type useless in a default configuration.

So careful with your blobs I like just storing the image on the HDD and a path/id in the DB. The advantages of storing in a db are very small, and it can be slower.

Community
  • 1
  • 1
austinbv
  • 9,297
  • 6
  • 50
  • 82
0

both are good. but i have always opted to using the actual file with giving the image an id. This is because your server and php has to do more work for a blob.

user706270
  • 131
  • 1
  • 3
0

The best idea is probably to store the actual file on the web/file server and only store the link to that file in the database. This keeps your database server from getting bogged down with unnecessary busy work.

Donnie
  • 6,229
  • 8
  • 35
  • 53
0

Check out http://transloadit.com, it's an service for uploading and storing (Amazon Cloud) images.

powtac
  • 40,542
  • 28
  • 115
  • 170
0

database storing can have a some advantages that are often forgotten.

  • you can backup your images along with your database, no filesystem backups needed for this.

  • it may be easier to scale when your site gets heavy traffic

of course its not suitable if you have a lot of images. like user contributed content etc.

but if you have a little newspaper site with not many articles online, you can perfectly store thumbnails in a database and build your system upon replication slaves.

however... honestly:

store your images on amazon s3. simple api, redundant, highly available and loadbalanced storage for cheap.

The Surrican
  • 29,118
  • 24
  • 122
  • 168
  • i always like downvotes without comment. – The Surrican Apr 20 '11 at 16:27
  • I am curious also about CSS and js files. pdf, swf and, say, xls are counted too. Is it good to store just whole site contents in a database to make filesystem backups really unnecessary? Are them filesystem backups that evil? – Your Common Sense Apr 20 '11 at 16:28
  • its another thing you need to take care of, monitor, program and maintain. if you just have IMAGES (as stated in the question) and there are not much (as stated as condition in my answer) it MAY be EASIER. i never used the word IS and gave a valid example. imagine you have a website with big articles that is only text based. and now you want a little image to show up as a preview on facebook. do you really want to set up a filesytem solution for that with all that comes along with it? – The Surrican Apr 20 '11 at 16:33
  • So, these poor pdf's illustrating some articles are doomed to be unsafe. What a pity... – Your Common Sense Apr 20 '11 at 16:38
  • 1
    umm another one file type just came to my mind. php files. let's say it's just ordinal hosting with no cvs to deal with sources. is it good idea to store source files in a database too? just to make sure that no filesystem backup needed ever? ugh, and web-server configs! And php binaries! Whoa, it's really amazing idea to store them all in a database! – Your Common Sense Apr 20 '11 at 16:39
  • Was the questions title "is it a good idea to store everything i can dream of in a database"? we are talking about images and images only here. and its perfectly possible to validate that only images get into the database. – The Surrican Apr 20 '11 at 16:43
  • we are talking of the **reasoning**. which is merely a `no filesystem backups needed for this.`, if you forget it. So, if I still have to backup filesystem - does that reason make that sense? – Your Common Sense Apr 20 '11 at 16:45
  • you are assuming that a you need a backup file system anyway. I am not. in the case that you have a database backup system in place and you ONLY and ONLY need to store a small number of images, it MAY be easier. what is so hard to understand? – The Surrican Apr 20 '11 at 16:47
  • yeah. you know, it's always hard to understand an *imaginary* solution – Your Common Sense Apr 20 '11 at 16:49
  • Not to mention your second "heavy traffic" reason. – Your Common Sense Apr 20 '11 at 16:51
  • If your images are part of your content (the "C" in CMS) then there is some sense to having them in the db with the rest of it. Sure, you can easily back them up from the filesystem, but Joe's advantages are reasonable (certainly more reasonable than associating them with the source files). That said, I have always stored images in the filesystem with a pointer from the db. – Greg Apr 20 '11 at 16:51
  • BTW, one additional reason for using the db is scaling. You can have multiple web heads pointing at a single db server and not worry about syncing/replicating files across them or using NFS or something for shared images. I wouldn't do this for user generated content but it sure would simplify things for the case where it is just an image or two with the content (i.e. the case Joe mentions). – Greg Apr 20 '11 at 16:55
0

I'd recommend saving them as regular static files. Then store their file names within your database. You can pull out the matching file name and either file_get_contents the image data or link directly to the real image file.

Don't store the image data itself within the DB.

Stevie
  • 245
  • 4
  • 9