Re: Images in Database

Yes, they can be dumped just fine.

I also don't understand what information you have that leads you to make the
claim that space is wasted. I guess it is due to your assumption that a
BLOB is used. A bytea type takes 4 extra bytes than the actual size of the
data. Furthermore, the field becomes part of a bigger file and therefore
will have less space loss due to differences between block size and file
size. Since that difference is a maxium per file, the fewer filesystem
files you have, the less space is lost.

As far as image searching, there are utilities that compare image files
already. If you need this for your app, I'm sure the procedure could be
duplicated in the RDBMS.
-----Original Message-----
From: pgsql-novice-owner(at)postgresql(dot)org
[mailto:pgsql-novice-owner(at)postgresql(dot)org]On Behalf Of Reshat Sabiq
Sent: Saturday, March 27, 2004 6:33 PM
To: Rod K
Cc: M. Bastin; pgsql-novice(at)postgresql(dot)org
Subject: Re: [NOVICE] 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.