Jump to content

Best Way To Store Photos


computermax2328

Recommended Posts

Hello All,

 

Every coder has their method that they become comfortable with when it comes to coding scripts and functions. One function I never really got comfortable with is photos. In the past I have just uploaded the file with a form, into a designated folder and then stored the location in a mysql database, so when I would call it from the database it would look something like this.

 

//Mysql select from database
$photo = photos/picture.png
<img src="../ echo '$photo'";

 

OBVIOUSLY, that is not proper php, but I am just trying to make a point. Does anyone suggest any other methods? I know some people use BLOB in phpmyadmin, but I have heard that it is php cardinal sin to use BLOB. Not really sure how it works either.

 

Any suggestions???

Link to comment
Share on other sites

Two teams: the developers and the database administrators.

- Developers tend to keep them as actual files and store information (like path and type) in the database. Makes things easier for them and less strenuous on the database. Files can easily be served by the webserver too, which means caching and typing and all that additional work is done automatically.

- DBAs tend to keep everything in the database. Backups are easy because all you have to do is replicate the database - which you should be doing anyway. I'm not good at presenting the advantages of this because I don't subscribe to it.

Link to comment
Share on other sites

Alright,

 

I do like to use the method I have been using. I guess I am trying to figure out how to make my code cleaner and more efficient. I feel like writing out the file path on every page is messy. Obviously, the file path is going to be different on every page. For example:

 

<img src="images/echo $photo"

 

or

 

<img src="../images/echo $photo"

 

You know what I mean? Different file paths for different level pages. Is there a way to clean up the code?

 

I would just like to mention that I am currently teaching myself php. This is just something I picked up this past summer. I am doing pretty well, but I just like to pick more experienced coders minds.

 

 

Link to comment
Share on other sites

If the directory with the images stay the same, but your pages are in different directories, you could just make a separate file with a variable that is set to the directory of the images. For example...

 

$imgdir = "http://yourdomain.com/images";

 

And on other pages...

 

include_once('image_include.php');
<img src="{$imgdir}/image.jpg" />

 

 

Link to comment
Share on other sites

- Developers tend to keep them as actual files and store information (like path and type) in the database. Makes things easier for them and less strenuous on the database. Files can easily be served by the webserver too, which means caching and typing and all that additional work is done automatically.

 

You also get to use something like Nginx to process the image requests, since it is faster than Apache for static things like that.

 

Or, you could take advantage of something like Amazon S3.

Link to comment
Share on other sites

It is easier to control access to the images if they are in a database.

 

How so? You can just as easily put images in directories that are not accessible via the internet. Since you would have to look up the image record in the DB to get the path/name you can just as easily control access as you could if the images were in the database.

 

I'm not trying to argue, just trying to understand the logic behind such a blanket statement.

Link to comment
Share on other sites

I'm not trying to argue, just trying to understand the logic behind such a blanket statement.

I'm sure about that....

I could not explain my logic very well in English.

My point of view about it, it's very near to post 17 - http://stackoverflow.com/questions/815626/to-do-or-not-to-do-store-images-in-a-database

Link to comment
Share on other sites

You mean the one with 17 upvotes? http://stackoverflow.com/a/815887

 

#1 is valid but easy enough to do in code.

#2 is true but your database becomes huge; storing images as files means you can put them on a separate share/drive (perhaps one dedicated to static files).

#3 is just as possible because the image metadata has to be stored anyways, and the images can ("should") be stored using random names (which is also a downside).

#4 is a pro for DBAs.

#5 sounds like it's refuting an old claim which apparently isn't true anymore.

I'm not sure that #6 is universally or commonly true, but I'm not a DBA.

 

Another downside is latency between a webserver and database server: imagine transferring a 10MB image from a remote connection (admittedly rare nowadays).

Link to comment
Share on other sites

I'm afraid you have to quote the section you're referring to, Jazzman1. There were a lot of posts there, and none of them identified as #17 (nor was "near the end" enough for me to figure out what, exactly, you were talking about).

What I can say, however, is that it's trivial to limit access to files on any *nix-compatible system: chmod and chown is all you need. It's true that the root user (admin) still can see them, but that's also true for a DBA.

Link to comment
Share on other sites

A big disadvantage to storing them in the DB is that there's no 'good' way to securely delete them.

Why ? There is no problem to create "read only views" users permissions. 

 

I'm talking about secure deletion from the hard disk.

 

Linux - srm

Windows - sdelete

 

http://en.wikipedia.org/wiki/Data_remanence

 

Depends on your clients needs though, just a disadvantage to think about, and a reason I always store data on the disk for client projects. If they want secure deletion now or later, I don't have to rebuild anything.

Link to comment
Share on other sites

What I can say, however, is that it's trivial to limit access to files on any *nix-compatible system: chmod and chown is all you need. It's true that the root user (admin) still can see them, but that's also true for a DBA.

 

That's completely irrelevant, because the webserver needs to be able to access them or nobody can see them.

Link to comment
Share on other sites

What I can say, however, is that it's trivial to limit access to files on any *nix-compatible system: chmod and chown is all you need. It's true that the root user (admin) still can see them, but that's also true for a DBA.

 

That's completely irrelevant, because the webserver needs to be able to access them or nobody can see them.

It's more relevant if the server is running scripts setuid'd as the script's owner. But that's quite rare to see that.

Link to comment
Share on other sites

Well, guys, you are younger than me and obviously you have much more knowledge than I am.

When I've started as a programmer few years ago, my boss said - "All sensitive data must be save into the DB" and for good or for evil, I'm doing it in this way.

As I mentioned before, I'm glad to be a part of this forum.

@Christian, sorry for wasting your time to seek a post # 17  :D

Link to comment
Share on other sites

Well, guys, you are younger than me and obviously you have much more knowledge than I am.

When I've started as a programmer few years ago, my boss said - "All sensitive data must be save into the DB" and for good or for evil, I'm doing it in this way.

As I mentioned before, I'm glad to be a part of this forum.

@Christian, sorry for wasting your time to seek a post # 17  :D

 

Younger? Not necessarily. But, no one is saying you can't or shouldn't store the images in the DB, only that saying it is more secure is a subjective statement. It is quite possible to store images in the DB that would be less secure than storing them as files. But, this question got way off base because I don't believe the OP ever mentioned anything about these being sensitive images. There are benefits and drawbacks to storing images in either the DB or in the file system. Each problem requires appropriate analysis to determine the best solution.

 

FYI: Regarding the reference to "Post #17", I think you misunderstood. There is no post #17 on that page. At least not one that stands out. The numbers to the left of the posts is the number of "Votes" the post received. The comment was just a clarification/confirmation.

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.