Re: Images in Database

Valid point. Maintenance might be easier (although i don't think you can dump and move images easily to another DB; you'd probably have to do some kind of direct connection to another DB to move them). When in a filesystem, you could bzip everything, and move them easily. There could also be an URL-prefix field for each client, followed by a URL suffix field for each image. Thus maintenance most of the time would be as easy as changing the prefix.
However, no matter how small an image is, it takes the same amount of BLOB space, doesn't it. This, IMHO, means a lot of wasted storage. Not sure if that also affects performance to some small degree. Storage is cheap, but still it costs money.

So, still it looks to me storing multi-media w/o additional benefits isn't quite worthwhile. But if there was something like find image LIKE another image, then i'd change my opinion in a sec. :)
But then again, i'm not against it. I just think it doesn't buy much, and wastes storage space.

-- 
Sincerely,
Reshat.
---
If you see my certificate with this message, you should be able to send me encrypted e-mail. 
Please consult your e-mail client for details if you would like to do that.

Rod K wrote:

I couldn't agree more.  I used to subscribe to the notion that there wasn't
a benefit to storing images in the DB.  After some heartache, I've had to
eat my words.

We have a solution where we receive hourly updates from an external source.
The updates include CSV files that are parsed into the DB and tar'd jpgs.
The original procedure called for the images to be stored in the filesystem,
and that worked fine for awhile.  Unfortunately, it didn't scale very well.
Now, we have multiple clients using the same data/images on their websites.
For now, all sites are served off the same server so a symbolic link to the
directory where the images exist for each site would work, but we'll most
probably not have all the sites on one web server as we grow.  Now, we're
talking about over 4GB of images and growing.  Maintaining multiple copies
would be a nightmare.  Moving the images to the RDBMS was the only scalable
solution.

Furthermore, having the images in the DB means they get backed up with the
DB.  Since the web site pages/scripts/etc are very static, we can do with
less frequent backups of that system now that the images are gone from
there.
 

-----Original Message-----
From: pgsql-novice-owner@postgresql.org
[mailto:pgsql-novice-owner@postgresql.org]On Behalf Of M. Bastin
Sent: Saturday, March 27, 2004 2:12 PM
To: Reshat Sabiq
Cc: pgsql-novice@postgresql.org
Subject: Re: [NOVICE] Images in Database


At 12:34 PM -0600 3/27/04, Reshat Sabiq wrote:   

I think unless the DB provides some image-searching capabilities,
it's better to store them as paths to save the space. A lot of
storage will be wasted otherwise. Isn't that so?     

PostgreSQL has no limit on storage except for the hard disk's limit.
You shouldn't worry about that.

The trouble with paths is that you must be able to resolve them from
any client that connects to your database.   It's also harder to move
the entire database afterwards if you must, or to otherwise
reorganize your directories.

Having everything in your database is much much cleaner and will save
you a lot of headache when you modify your solution in a next
programming round.

Cheers,

Marc

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org