Re: Image Question
From: Trev Hunter (hunter_trev_at_hotmail.com)
Date: 02/15/04
- Next message: Andy Eshtry: "Re: Error: No default member found for type MyClass"
- Previous message: Ian: "DirectX DirectSound + AudioVideoPlayback"
- In reply to: Tom Leylan: "Re: Image Question"
- Next in thread: Tom Leylan: "Re: Image Question"
- Reply: Tom Leylan: "Re: Image Question"
- Messages sorted by: [ date ] [ thread ]
Date: Sun, 15 Feb 2004 00:32:19 -0000
> I'm happy to see that someone posted a
> thought process rather than just an
> "opinion"
Cheers, but some of the first words in my post were "IMHO" ;)
> 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...
I admit, I was wrong to make so many assumptions about what the final
product will be doing and how it will do it. I based my assumptions on an
app that I recently wrote that stores documents of all types in a central
database. I was wrong to assume that the OP's application was similar
without more information. I did happen to notice your first post made the
opposite assumption that there isn't any advantage to storing the images in
the database though...
If ya have the time, let me explain my design (and hence my recommendations
based on these assumptions):
1) The Application will be used to store documents in a central location
(this can apply to a web server, email application, windows application
etc). This will involve users selecting a document from their local machine
and "uploading" it to the server.
2) When the user wants to view the file, they query the server. At this
point, if there is no record in the database, the user can't get the file,
so effectively there is no file anymore (even if there is a orphan file
somewhere on the server that had its record deleted).
3) If a user deletes a file from the server, it is deleted from the server,
not the location that they originally uploaded it from.
To respond to your comments:
> Synchronization for instance...
> if you delete the record you have
> effectively erased the image. Are we
> certain destroying the image is the goal?
See point (3) and again, sorry for the assumption.
> If images are duplicated (the
> "no image available" image for
> instance) then you have stored
> (possibly) hundreds of copies of that image.
I would expect a bit of common sense on the part of the database schema and
application design to handle these situations. To handle no image available,
store Null and have a default image elsewhere. To handle multiple copies of
the same image, implement the schema with a join table and implement the UI
so that the user gets prompted if a similar image exists (based on other
data about the image).
> Do you want to store
> .jpeg, .gif and .png in
> three separate columns?
Again, a little bit of design intelligence would do here.
> Would you suggest the same thing if the
> guy was storing 20,000 video files?
Probably not. They *did* state their requirements on this point in the
original post though. The reason why I wouldn't recommend it is because of
one of the con's mentioned in my first post (the part about maintaining a
large single file for backups etc.) would far outweigh the benefits of
storing in the database.
> 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?
Again, my bad for making the assumptions.
> To conclude something
> with as little information as
> has been posted isn't typically a good idea...
Point taken and I'll be more careful in the future. I hope you can do the
same before posting responses like your original one:
> I can't see any particular
> advantage to storing the
> images in the database
> can you? I can think of
> a number of key reasons not to.
Thanks for the discussion. Hopefully I'll learn not to make assumptions like
this in the future.
Trev.
"Tom Leylan" <gee@iamtiredofspam.com> wrote in message
news:%23WEG6Z08DHA.1804@TK2MSFTNGP12.phx.gbl...
> 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
>
>
- Next message: Andy Eshtry: "Re: Error: No default member found for type MyClass"
- Previous message: Ian: "DirectX DirectSound + AudioVideoPlayback"
- In reply to: Tom Leylan: "Re: Image Question"
- Next in thread: Tom Leylan: "Re: Image Question"
- Reply: Tom Leylan: "Re: Image Question"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
