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(at)postgresql(dot)org
>>[mailto:pgsql-novice-owner(at)postgresql(dot)org]On Behalf Of M. Bastin
>>Sent: Saturday, March 27, 2004 2:12 PM
>>To: Reshat Sabiq
>>Cc: pgsql-novice(at)postgresql(dot)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(at)postgresql(dot)org
>>
>>
>>
>>
>
>
>
>
>