Re: Image Question
From: Tom Leylan (gee_at_iamtiredofspam.com)
Date: 02/14/04
- Next message: Rob Windsor [MVP]: "Re: No touch deployment"
- Previous message: Bernie Yaeger: "Re: HOWTO: Iterate thru dataset rows changing field values"
- In reply to: Trev Hunter: "Re: Image Question"
- Next in thread: Trev Hunter: "Re: Image Question"
- Reply: Trev Hunter: "Re: Image Question"
- Messages sorted by: [ date ] [ thread ]
Date: Sat, 14 Feb 2004 17:04:12 -0500
Trev,
I'm happy to see that someone posted a thought process rather than just an
"opinion" but consider that we don't know anything about the images like how
often they may change, what they are used for, etc. To conclude something
with as little information as has been posted isn't typically a good idea...
Synchronization for instance... if you delete the record you have
effectively erased the image. Are we certain destroying the image is the
goal? Where is the original, if we're lucky in yet another folder on the
hard drive, if we're unlucky it's gone.
If images are duplicated (the "no image available" image for instance) then
you have stored (possibly) hundreds of copies of that image. Will the
system eventually have to support multiple formats? Do you want to store
.jpeg, .gif and .png in three separate columns?
Would you suggest the same thing if the guy was storing 20,000 video files?
What size of file would stop at and what if there was a combination of
20,000 images and 10,000 very large video files?
And as for "you don't have to worry about the file i/o" again we don't
really know if that is the entire purpose of the database of images right?
How do they get uploaded and are they available for download?
Tom
"Trev Hunter" <hunter_trev@hotmail.com> wrote...
> Stan,
>
> IMHO, here's some of the pros and cons of storing the image data in the
> database as opposed to just a link the file:
>
> Pro's
> --------
> 1) Synchronization is easier if you store the data in the database
because:
> a) If you delete the image record, you don't have to worry about deleting
> the file
> b) If the file is moved, links in the database may be broken as a result
> c) If you move the database (e.g. because you're changing the server), you
> don't have to worry about moving the files too and maintaining all the
links
>
> 2) You don't have to worry about duplicate file names for the image files
>
> 3) If your database is located on a network server, but the images are
> scattered on client machines then maintaining links will be a nightmare.
> Having the images as part of the database would be an advantage.
>
> Con's
> -------
> If you corrupt your database, all images are lost, not just one or two
(but
> if you don't keep backups then well...)
>
> If you use a database that stores the database as one file (e.g. Access),
> then this one file may become pretty big, so copying it and backing it up
> will be a bit more hassle because you may have to split it.
>
>
> I would tend to go for storing the data in the database, not only because
of
> the benefits above, but because its easier to program as you don't have to
> worry about all the file IO and directory permissions etc.
>
> Hope this helps,
>
> Trev.
>
>
>
> "Stan Sainte-Rose" <stan@cyber972.com> wrote in message
> news:%23gvTeUy8DHA.4044@tk2msftngp13.phx.gbl...
> > Hi,
> > What is the better way to save image into a database ?
> > Just save the path into a field or save the image itself ?
> > I have 20 000 images (~ 10/12 Ko per image ) to save.
> >
> > Stan
- Next message: Rob Windsor [MVP]: "Re: No touch deployment"
- Previous message: Bernie Yaeger: "Re: HOWTO: Iterate thru dataset rows changing field values"
- In reply to: Trev Hunter: "Re: Image Question"
- Next in thread: Trev Hunter: "Re: Image Question"
- Reply: Trev Hunter: "Re: Image Question"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
