images in sql db's

[yawnmoth]

i have a script that accesses images on a fairly frequent basis,
however, i'm thinking that it would be better to have them in an sql
database, instead, for the same reason that it is generally preferable
to access data in an sql database over a text file. the images are
small (i don't think any exceed 350 bytes), so i don't expect it'll
put a lot of strain on the sql server.

anyway, i currently load the images using ImageCreateFrom GIF, and
place them into another image with ImageCopy. if i were to place the
images in an sql server, using ImageCreateFrom Gif obviously wouldn't
work. so what will?

any help would be appreciated - thanks! :)

[Michael Austin]

yawnmoth wrote:

i have a script that accesses images on a fairly frequent basis,
however, i'm thinking that it would be better to have them in an sql
database, instead, for the same reason that it is generally preferable
to access data in an sql database over a text file. the images are
small (i don't think any exceed 350 bytes), so i don't expect it'll
put a lot of strain on the sql server.

anyway, i currently load the images using ImageCreateFrom GIF, and
place them into another image with ImageCopy. if i were to place the
images in an sql server, using ImageCreateFrom Gif obviously wouldn't
work. so what will?

any help would be appreciated - thanks! :)

actually, from a DBA point of view, I would just store a pointer to the
file in the database and read it when necessary... doing BLOBS, CLOBS
etc in a db is nice, but can get real messy when trying to manage that
space -- especially if you are not a "real" dba and you are not real
sure what you are doing or how to do it...

Michael Austin.

[Tony P.]

In article <iq************ ***@newssvr24.n ews.prodigy.com >,
ma*****@firstdb asource.com says...

yawnmoth wrote:

i have a script that accesses images on a fairly frequent basis,
however, i'm thinking that it would be better to have them in an sql
database, instead, for the same reason that it is generally preferable
to access data in an sql database over a text file. the images are
small (i don't think any exceed 350 bytes), so i don't expect it'll
put a lot of strain on the sql server.

anyway, i currently load the images using ImageCreateFrom GIF, and
place them into another image with ImageCopy. if i were to place the
images in an sql server, using ImageCreateFrom Gif obviously wouldn't
work. so what will?

any help would be appreciated - thanks! :)

actually, from a DBA point of view, I would just store a pointer to the
file in the database and read it when necessary... doing BLOBS, CLOBS
etc in a db is nice, but can get real messy when trying to manage that
space -- especially if you are not a "real" dba and you are not real
sure what you are doing or how to do it...

Indeed - blobs and globs are space wasters. You're better of pointing to
a file that contains the image. But again, it would take the pointer
size + file size whereas with a blob/glob you eliminate the need for
that pointer.

[Andy Hassall]

On Sun, 30 May 2004 02:12:30 GMT, Michael Austin <ma*****@firstd basource.com>
wrote:

yawnmoth wrote:

i have a script that accesses images on a fairly frequent basis,
however, i'm thinking that it would be better to have them in an sql
database, instead, for the same reason that it is generally preferable
to access data in an sql database over a text file. the images are
small (i don't think any exceed 350 bytes), so i don't expect it'll
put a lot of strain on the sql server.

anyway, i currently load the images using ImageCreateFrom GIF, and
place them into another image with ImageCopy. if i were to place the
images in an sql server, using ImageCreateFrom Gif obviously wouldn't
work. so what will?

any help would be appreciated - thanks! :)

actually, from a DBA point of view, I would just store a pointer to the
file in the database and read it when necessary... doing BLOBS, CLOBS
etc in a db is nice, but can get real messy when trying to manage that
space -- especially if you are not a "real" dba and you are not real
sure what you are doing or how to do it...

Whilst that's often true, just to put the other side of the argument across -
if you do store images in the database, then you only have one thing to backup,
and so it greatly simplifies the problems of the database and the filesystem
getting out of sync. Also, your images then have the same transactional
guarantees as your data.

Depends how important your images are, and whether your database can handle
the volume. A cache on the filesystem (with the database as the master) can
alleviate some of the load if you did store in the database.

You're right that for most websites storing the path to the image is the way
to go.

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

[Andy Hassall]

On Fri, 28 May 2004 23:55:03 GMT, yawnmoth <te*******@yaho o.com> wrote:

i have a script that accesses images on a fairly frequent basis,
however, i'm thinking that it would be better to have them in an sql
database, instead, for the same reason that it is generally preferable
to access data in an sql database over a text file. the images are
small (i don't think any exceed 350 bytes), so i don't expect it'll
put a lot of strain on the sql server.

anyway, i currently load the images using ImageCreateFrom GIF, and
place them into another image with ImageCopy. if i were to place the
images in an sql server, using ImageCreateFrom Gif obviously wouldn't
work. so what will?

any help would be appreciated - thanks! :)

Look up imagecreatefrom string - creates GD image resources from binary data
stored in strings.

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