Storing images instead of image paths in DB

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

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


Re: Storing images instead of image paths in DB

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


Re: Storing images instead of image paths in DB wrote:

Quoted text here. Click to load it

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  
(Unless you think that 'storing images in database' is the extra  

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.

Just my 2 cents.

Erwin Moller

Quoted text here. Click to load it

Re: Storing images instead of image paths in DB wrote:

Quoted text here. Click to load it
   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.

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

Re: Storing images instead of image paths in DB


Quoted text here. Click to load it

 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.

< Space: disk usage analysis tool

Re: Storing images instead of image paths in DB

Quoted text here. Click to load it

  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.

FREE Avatar hosting at

Re: Storing images instead of image paths in DB

Norman Peelman wrote:
Quoted text here. Click to load it

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


Site Timeline