How do you guys handle this?

Phrank

I have a ton of images. Basically a car lot type of business. In order to give the user the flexibility of adding and deleting and changing the images I thought a seperate database of images would be better than using the Image directory.

How do you guys handle this problem? Do you save all images in a directory and work with directory commands to delete etc?

Anyone agree that it would be better to have a dtabase of images to present a more friendly user interface?

Am having lots of problems with displaying images from a database as opposed to a directory.

Any comments would be greatly apprecaited.

TIA

Frank

nemonoman

In my opinion storing binary image data in database records is nutty. Better to keep a pointer to an image stored in a separate directory. You manage the image set using the database. When someone wants to delete an image, you find the image address and unlink() it, then delete the database record. And so on.

drawmack

There are a couple of things to consider

1) If you use files then you have to make sure you clean up after yourself, where as most of this is handled for you if you use the database

2) What type of database are you using. Some are better at handeling large chunks of data (i.e. images) then others.

3) How much protection do you want on the images. Putting them in the database puts another layer on the onion.

4) How many records will the database store. If the database is already going to be huge then you should probably not put binary data into it, but if the database is going to be small then it is probably okay to just stick them in the database.

AstroTeg

What you have here is valid, but just some counter points:

Originally posted by drawmack
1) If you use files then you have to make sure you clean up after yourself, where as most of this is handled for you if you use the database

Putting it in a database to work around cleanup is being lazy. Its not difficult to create you're own delete function to delete from a DB and the directory. Sure, it'll take a few more minutes to write, but it'll be worth it.

Originally posted by drawmack
2) What type of database are you using. Some are better at handeling large chunks of data (i.e. images) then others.

Even MS SQL has issues with blobs (under v7 & v2000). Another concern is databases are not all created equal. When it comes time to port your solution to another web server and database engine, you may find it much more painful if you have to rewrite code and create work arounds for unexpected blob issues. The other approach of putting the files in a directory would completely save you of this worry and hassle.

Originally posted by drawmack
3) How much protection do you want on the images. Putting them in the database puts another layer on the onion.

Protection is the responsibility of the coder, not the DB. With a file system setup, you can store the images in a non-web accessible directory and use PHP to validate the user and then read the bits and feed them back to the browser (or use .htaccess). This is exactly the same way you would do it with a database, the only difference is there's very little burden on the database engine if all it has to do is validate a user versus trying to validate a user and send back a file as well.

Originally posted by drawmack
4) How many records will the database store. If the database is already going to be huge then you should probably not put binary data into it, but if the database is going to be small then it is probably okay to just stick them in the database.

Thinking this way is a trap in my opinion. Essentially, you end up building an app that doesn't scale well. Its the classic, "build it right the first time" is my approach. But this is just opinion.

drawmack

Originally posted by AstroTeg
Putting it in a database to work around cleanup is being lazy. Its not difficult to create you're own delete function to delete from a DB and the directory. Sure, it'll take a few more minutes to write, but it'll be worth it.

Possibly, but what if the eventuallity of porting to a different OS, which will need a different clean up routine exists? Then you are building an application that doesn't scale well.

Even MS SQL has issues with blobs (under v7 & v2000). Another concern is databases are not all created equal. When it comes time to port your solution to another web server and database engine, you may find it much more painful if you have to rewrite code and create work arounds for unexpected blob issues. The other approach of putting the files in a directory would completely save you of this worry and hassle.

I doubt that someone using oracle is going to port to another db and that's the one that I had in mind. MS SQL server sucks IMO.

Protection is the responsibility of the coder, not the DB. With a file system setup, you can store the images in a non-web accessible directory and use PHP to validate the user and then read the bits and feed them back to the browser (or use .htaccess). This is exactly the same way you would do it with a database, the only difference is there's very little burden on the database engine if all it has to do is validate a user versus trying to validate a user and send back a file as well.

Okay and if your file system gets compromised then your files are compromised, putting them in the db means that you can easily add obfuscation with table/field names and such.

Thinking this way is a trap in my opinion. Essentially, you end up building an app that doesn't scale well. Its the classic, "build it right the first time" is my approach. But this is just opinion.

There are database driven sites that do not need the ability to scale.

AstroTeg

Possibly, but what if the eventuallity of porting to a different OS, which will need a different clean up routine exists? Then you are building an application that doesn't scale well.

You pretty much only have 2 big players: *nix and Wintel. And if you're using PHP, then the unlink works on both. The trick would be the database. Use ADODB and even that shouldn't cause a big problem.

I doubt that someone using oracle is going to port to another db and that's the one that I had in mind. MS SQL server sucks IMO.

Worst case could be a PHP/MySQL to an ASP/MS SQL setup. MS SQL has issues with blobs. Use the file system and its a no brainer.

Okay and if your file system gets compromised then your files are compromised, putting them in the db means that you can easily add obfuscation with table/field names and such.

Assuming its a typical LAMP setup, the MySQL is running on the same server as the web server and PHP code. The file system gets compromised, the thug can get to the data regardless of how its stored. Sure, the DB adds one additional layer, but the thug just grabs the PHP code as well and problem solved. If you really want to be secure, implement file encryption before storing the file. In this situation, it doesn't matter if the file is in the database or on the file system (and if it was encrypted, there is still a good risk they could get to the files).

Phrank

I have been programming since the 60's. Putting images in a directory on the server seems a step back. Just got into web site design and already have 8 to do (and of course they are all in a hurry!).

I am using php with mysql. Learning both. I would like to present the user with a clean interface. Also, I would like to be able to easily port the site to other isp's with relative ease. I can back up a database of images much easier than a set of directories.

But, almost everyone is using directories that I have talked to.

If I could just show an image from a db I would rather use a db. I can't seem to get that to work when I include other things on the page.

You know - find the record - and echo the image along with some other stuff on the page.

Nobody has been able to help with that.