1

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.

user2684521
  • 380
  • 4
  • 20
  • If one or more answers are correct you should accept (and upvote if appropriate) one so other users of this site know which one is best and correctly answered your question. – Tristan Nov 27 '15 at 21:19

1 Answers1

0

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.

Community
  • 1
  • 1
Tristan
  • 3,301
  • 8
  • 22
  • 27