Best Way To Store Photos

[computermax2328]

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???

[requinix]

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.

[Pikachu2000]

Personally, since images are actually files, I feel the proper place for them is in the filesystem like you're doing it now.

[computermax2328]

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.

 

 

[DomenicF]

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" />

 

 

[White_Lily]

I dont like using blob. i tend to use VARCHAR in phpMyAdmin, and it works fine for me. and from what my code is the php is pretty simple, although im using the code for avatars and banner images.

 

 

What i do is store the image in a directory, and the filename in the database.

[spiderwell]

for me its always been files in a folder, then filename and path in the database (as seperate columns).

[Jessica]

Personally, since images are actually files, I feel the proper place for them is in the filesystem like you're doing it now.

Agreed.

[scootstah]

- 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.

[jazzman1]

It really depends!

If your images are very important as security documents, medical research, etc..... the best way for me to save them in DB, otherwise I prefer Pika's solution.

[Psycho]

If your images are very important as security documents, medical research, etc..... the best way for me to save them in DB . . .

 

Hmm . . . could you provide some reasoning for that statement? I'm not following that.

[xyph]

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

[jazzman1]

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

 

[jazzman1]

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. 

[Psycho]

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.

[jazzman1]

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

[requinix]

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

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).

[Christian F.]

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.

[xyph]

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.

[scootstah]

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.

[requinix]

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.

[jazzman1]

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 

[spiderwell]

i guess it depends on the image whether it is sensitive or not.

the ones on my phone are

 

[Psycho]

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 

 

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.