Subject | Re: [ib-support] Inserting BLOBs with ODBC |
---|---|
Author | Didier |
Post date | 2003-05-01T07:38:37Z |
lportersr wrote:
I would personnally NOT use a db to store images. I would store path to
them & save them on your good old hard drive with a calculated set of
directories. This opinion comes from 10 years bacground in image stock
libraries, in various european/US companies handling large amounts of
pictures and NONE have ever been stored in a db.
Plus points:
A: db does not grow as fast, keeps it manageable & does not give backup
& restore headaches.
B: image handling : easy backups, burned on CD/DVD. if you need batch
handling (making thumbnails .... easy to do if you're on disk not
on-database.)
C: it is not likely to have to update part of an image (it is generally
a all-or-nothing type of update). I do not see the benefit of using a DB
engine to store an image
D: easy to spread the load between an db/application server & image
delivering server. Scales nicely
E: downgrades nicely if one image is corrupted, you don't run the risk
of corrupting the whole db.
Minus point:
A: got to remember that under Win$ you probably do not want to have too
many entries in one single directory.
B: It can be messy to administer: so very careful planning, depending on
the number of images you want/need to handle
HTH
Didier
> I am currently working on a Windows-based project that will use ODBCMike,
> to connect to a database. I will be storing images (about 66k) and am
> wondering how this can be done using ODBC.
>
> I have some experience with databases, but have never done images. How
> exactly would you do this?
I would personnally NOT use a db to store images. I would store path to
them & save them on your good old hard drive with a calculated set of
directories. This opinion comes from 10 years bacground in image stock
libraries, in various european/US companies handling large amounts of
pictures and NONE have ever been stored in a db.
Plus points:
A: db does not grow as fast, keeps it manageable & does not give backup
& restore headaches.
B: image handling : easy backups, burned on CD/DVD. if you need batch
handling (making thumbnails .... easy to do if you're on disk not
on-database.)
C: it is not likely to have to update part of an image (it is generally
a all-or-nothing type of update). I do not see the benefit of using a DB
engine to store an image
D: easy to spread the load between an db/application server & image
delivering server. Scales nicely
E: downgrades nicely if one image is corrupted, you don't run the risk
of corrupting the whole db.
Minus point:
A: got to remember that under Win$ you probably do not want to have too
many entries in one single directory.
B: It can be messy to administer: so very careful planning, depending on
the number of images you want/need to handle
HTH
Didier
>
> Mike...
>
>
>
> To unsubscribe from this group, send an email to:
> ib-support-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>