Storing images instead of image paths in DB

[bissatch]

Hi,

I am currently writing a news admin system. I would like to add the
ability to add images to each article.

What I have always done in the past is uploaded (using a form) the
image to a folder on the server and then in the database table that I
INSERT the news article, I'll store the path of the uploaded image.

To me this seems a bad idea as if the image paths were changed on the
server (cant think why, but still worth considering) the database
wouldnt reflect this.

The other alternative would be to store the images in the database.
This way the images and the image path wouldn't be two seperate
entities. Is this is preferred option? If so, where can I learn more?
Also, the databases I am using is PostgreSQL (this cant change). Does
this support storing data entries?

Any suggestions would be much appreciated, thanks

Burnsy

[Sergej Andrejev]

I think you should store images in database only if your site ofted
moves, cos storing images in database greatly load your database, which
may result in lose of speed.

Ofcource PostgreSQL suports storing images in database, it's just your
script work to convert it to useble form

Read more on
http://codewalkers.com/tutorials/35/3.html

[Erwin Moller]

bi******@yahoo.co.uk wrote:

Hi,

I am currently writing a news admin system. I would like to add the
ability to add images to each article.

What I have always done in the past is uploaded (using a form) the
image to a folder on the server and then in the database table that I
INSERT the news article, I'll store the path of the uploaded image.

To me this seems a bad idea as if the image paths were changed on the
server (cant think why, but still worth considering) the database
wouldnt reflect this.

The other alternative would be to store the images in the database.
This way the images and the image path wouldn't be two seperate
entities. Is this is preferred option? If so, where can I learn more?
Also, the databases I am using is PostgreSQL (this cant change). Does
this support storing data entries?
Well, why should you WANT to change from PostgreSQL?
It is a great robust database, and free.
Keep using it. :-)

And I never understood why people like to store images in databases, when
you can much more easily store them in a directorystructure.
Images only make your databasefiles much larger, and offer no extra
functionality.
(Unless you think that 'storing images in database' is the extra
functionality.)

you can easily achieve the same functionality by only storing the name (and
maybe path) of the image in the database.

So my advise: Don't. Just store the path to the image in the database.

One possible problem you might encounter is the fact that if more people can
upload images, you overwrite files with the same name.
So do not let the client choose the name of the image, be sure you pick it.
eg:
<articleid>_img.png
or
<articleid>_img.jpg

Just my 2 cents.

Regards,
Erwin Moller

Any suggestions would be much appreciated, thanks

Burnsy

[Alexey Kulentsov]

bi******@yahoo.co.uk wrote:

To me this seems a bad idea as if the image paths were changed on the
server (cant think why, but still worth considering) the database
wouldnt reflect this. No problem. Use abstract image tag in articles and translate it to
real tag before output. User must know only image ID to insert it to
article. For example <preview id="123"/> or <image number="123"/>
After translation result will be like <IMG
SRC="path/to/images/pic_123.jpg" ALT="$image_title" WIDTH="xxx"
HEIGHT="yyy" AND_SO_ON.. />
If you will change your paths structure you just correct translation
procedure and all links in articles will be valid.
The other alternative would be to store the images in the database.

Never store image in database. Database can't index images so you have
no any reason to store it in SQL server.

[Andy Hassall]

On Thu, 04 Aug 2005 23:54:11 +0300, Alexey Kulentsov <cr*******@crimaniak.com>
wrote:

The other alternative would be to store the images in the database.

Never store image in database. Database can't index images so you have
no any reason to store it in SQL server.

Untrue - two clear advantages are:

(1) The image data is under the same transactional control as the rest of the
data. If your server crashes, then you don't have any guarantee that the
filesystem is in sync with the database any more. And you can't ROLLBACK a
filesystem change.

(2) Having the images in the database means you only have to backup one thing,
and similar to (1) you know that your image data is referentially correct
compared with the rest of the data.

There are disadvantages to storing image data in the database, some of which
can be alleviated with caching in the filesystem, but to say there is no reason
to store images in the database is not true.

--
Andy Hassall / <an**@andyh.co.uk> / <http://www.andyh.co.uk>
<http://www.andyhsoftware.co.uk/space> Space: disk usage analysis tool

[Norman Peelman]

"Andy Hassall" <an**@andyh.co.uk> wrote in message
news:el********************************@4ax.com...

On Thu, 04 Aug 2005 23:54:11 +0300, Alexey Kulentsov <cr*******@crimaniak.com> wrote:

The other alternative would be to store the images in the database.Never store image in database. Database can't index images so you have
no any reason to store it in SQL server.

Untrue - two clear advantages are:

(1) The image data is under the same transactional control as the rest of

the data. If your server crashes, then you don't have any guarantee that the
filesystem is in sync with the database any more. And you can't ROLLBACK a
filesystem change.

(2) Having the images in the database means you only have to backup one thing, and similar to (1) you know that your image data is referentially correct
compared with the rest of the data.

There are disadvantages to storing image data in the database, some of which can be alleviated with caching in the filesystem, but to say there is no reason to store images in the database is not true.

--
Andy Hassall / <an**@andyh.co.uk> / <http://www.andyh.co.uk>
<http://www.andyhsoftware.co.uk/space> Space: disk usage analysis tool

I have to agree with Andy on this one... for both reasons he pointed out.
And most of the time you can pull in your image data right along with
everything else in the same query. If you have a small number of images you
would be ok to do it either way and the filesystem method would probably not
be too bothersome but, if you are looking to be storing thousands or more
then you will probably need to programmatically break up the directory
strucure so as to not overload the filesystem (too many files in one
directory can really slow down a filesystem, not to mention the filesystem
limitations) such as alphabetically, numerically, etc. The GD functions
really make this easy by the way.

Norm
---
FREE Avatar hosting at www.easyavatar.com

[NC]

Norman Peelman wrote:

"Andy Hassall" <an**@andyh.co.uk> wrote in message
news:el********************************@4ax.com...

On Thu, 04 Aug 2005 23:54:11 +0300,
Alexey Kulentsov <cr*******@crimaniak.com> wrote:

Never store image in database. Database can't index images so you have
no any reason to store it in SQL server.

Untrue - two clear advantages are:

(1) The image data is under the same transactional control as
the rest of the data. .... (2) Having the images in the database means you only have to
backup one thing,

I have to agree with Andy on this one... for both reasons he pointed out.
And most of the time you can pull in your image data right along with
everything else in the same query.

As a matter of fact, most of the time you can't do it. You need
a separate script to pose as a picture. So if you have a page
that pulls text data and references three images, you will have
four nearly simultaneous connections, one for the text page and
three for three instances of picture-rendering script.

This could quickly change at some point if all browsers begin to
understand the <img data=""> tag; then there will be no need for
separation of HTML and image output. Unfortunately, we are not
quite there yet...

There is also a workaround, whereby the HTML-rendering script
retrieves image data from the database and stores images in
session variables and then passes the variable names to
picture-rendering scripts, which retrieve image data not from
the database, but from the session variable referenced.

Andy is absolutely right when he says that storing images in a
database leads to stricter transactional control and easier data
maintenance. But the developer needs to understand that this
architecture creates additional overhead that cannot be overcome
from within PHP; Andy's proposed solution is to cache images,
which is another way of saying "store image copies on disk, but
keep normative versions in the database".

Actually, a similar approach is used by some content management
systems which allow for separation of authoring and publishing.
An author submits text and images; they are stored in a database.
When the editor publishes the submission, static HTML and image
files are created (not necessarily on the same physical machine).

Cheers,
NC