Image Question

[Stan Sainte-Rose]

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

 

[Scott M.]

Did someone say it was better to store them in a DB?

 

[Herfried K. Wagner [MVP]]

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.

I would store them in the database.

;-)

 

[Tom Leylan]

Hi Stan,

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.

Tom

 

[Terry Williams]

It guess, it would depend on the type of application.

For a web application, I think it would be best to store a image path to
a database, but actually store the image in a directory, and not bloat
your database.

For a desktop c/s application, I think it would best to store the image
in a database, then having to access a shared resource to access the
image.

 

[Trev Hunter]

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.

 

[Tom Leylan]

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

 

[Herfried K. Wagner [MVP]]

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.

Easier deployment may be a reason for storing everything in the
database. No "dangling" filenames/paths may be another reason.

 

[Trev Hunter]

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]

It might but that would depend upon "deployment" and it wasn't mentioned.
Nor was the database.

If a solution is faster, easier and more reliable it seems like a good
reason to use it but I'm not certain we know that putting 10,000 images in a
database is any of those things.

 

[Tom Leylan]

Cheers, but some of the first words in my post were "IMHO"

Clearly most replies are opinions but it is nice when people post the
rational behind. Situations are different and therefore perhaps the
conclusion.

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...

It is great that you have experience with it. I was going to suggest to the
OP that he seek out people doing this type of thing (whatever it is he is
doing) so that he didn't just get responses based upon people taking 15
seconds out to reply. I'll admit that believe he will be at least "as well
off" by keeping the images outside but I intended to ask him what he thought
the advantages might be for storing them in the database. I can't think of
many... that doesn't mean that we can't post "it will be easier" but is that
in fact a "fact"?

Perhaps... how does he get 10,000 images into the database attached to the
proper records?

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.

I would have guessed from the short description that users wouldn't directly
upload files. So that's interesting.

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).

I don't think I get this. But anyway, I would guess that a user could
select only from records in the database. If it isn't in the database then
it doesn't qualify for downloading and/or viewing. It doesn't matter if the
an image is sitting in folder... I have images sitting in folders on my
webserver, you can't get them

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.

Seems reasonable to me.

To respond to your comments:


See point (3) and again, sorry for the assumption.

We don't know that user routinely (if ever) keeps the images. Once
submitted they are "safely stored in the image archive" so what's the point?
Are the users working inhouse or subscribers to some service? I don't know
who owns the images.

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).

Seems reasonable.

Again, a little bit of design intelligence would do here.

Perhaps but maybe I didn't explain it correctly. I can choose (from a
number of websites) to view movie trailers in one of three distinct formats
and often in low or high bandwidth versions. This means they have 6
different copies of the same film stored. If it is an image database such
that people can purchase and download the images it isn't hard to imagine
that a thumbnail would be required. Probably a larger image and possibly
another hi-definition version.

see: http://pro.corbis.com/

for information on image storage see:
http://sunsite.berkeley.edu/Imaging/Databases/

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.

I agree. That's why I'm doubtful that storing the 10K images directly in
the database is a good idea. To be sure, it might be a great idea I just
(so far) don't think so.

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:

Sorry, I thought yours was the thoughtful response. Again I probably didn't
make myself clear on that. You gave "reasons" and so many times people just
post "opinions" never offering a basis for why they think what they think.


I see now... it was intended to be an invitation for discussion. Rather
than post "I think this... or that" I thought I might find out what the guy
with problem had thought about so far. He could be doing this for a large
corporation with a dedicated server and SQL Server or he could be putting
something together for the "dungeons and dragons" role-playing game he hosts
on a free internet site. I have no idea the kind of money or equipment (or
expertise) he has at his disposal.

Thanks for the discussion. Hopefully I'll learn not to make assumptions like
this in the future.

It isn't you Trev... it is the way people post stuff in general. That's one
of the reasons "which computer language is best" type questions generate so
much heat and so little light. Few people ask "what do you want to do with
it" before mentioning the language they know.

Take care,
Tom

 

[Cor]

Hi Herfried,

You know I am busy with this.

The trouble I have now.
I cannot convert all formats to and from the database.
I have the idea that I loose information converting it from and to

Can you help me to overcome this or tell me what is wrong or right of above?

Cor

 

[Cor]

Hi Stan,

I am busy with this so I cannot give you a complete answer.

I think it is very fine to use for thumbnails.
(Very fast processable)

For real images I am in doubt.

(If you want to know why see for that my question to Herfried)

Cor

 

[Stan Sainte-Rose]

Wowww
I never thought my post will get this mass of replies...
I thank you for your opinions..

Stan

 

[Trev Hunter]

Cor,

I've recently implemented a solution to store all types of files in a
database (I've used Access, but the same principals should work for other
databases too). Let me know if I can be of assistance.

Trev.

 

[Trev Hunter]

Clearly most replies are opinions but it

is nice when people post the
rational behind.

Agreed. It's always nice to get a bit of an explanation for solutions to
problems.

but I intended to ask him what he thought
the advantages might be for storing them in the database

Again, my bad for not asking the them to be a little more specific about the
requirements before posting my reply.

I can't think of many...

What advantages or disadvantages there may be depend on the requirements,
something that wasn't explained to either of us. I might have been wrong to
give pros and cons without the requirements (or providing my own explanation
for the pros and cons), but "I can't think of many..." is bordering on one
of those 15 second answers you mentioned (see why at *** below)

how does he get 10,000 images into the database attached to the
proper records?

The same way he gets 10,000 records in the database to point to the correct
files (although a bit slower because of the data transfer).

I would have guessed from the short
description that users wouldn't directly
upload files. So that's interesting.

I don't know your experience with applications that do this, but I guess I
was swayed because I recently implemented a solution to upload files to a
central location and chose to go the database route.

I don't think I get this. But anyway, I
would guess that a user could
select only from records in the database.

Yes. The solution I implemented stored the documents on a server. To view a
list of the available documents, the user queries the database (not the file
system) for descriptions of the files. If there isn't any record for the
document, there is no way to get the document (unless you stored outside the
db and could get to the file going "behind the scenes" of my server
application).

I guess the two different types of applications that could be implemented
are as follows (regardless of where the files are stored):

1) Where the database complements the files - i.e. The user has a set of
files and then an auxiliary database designed to provide descriptions of the
files.

2) Where the database controls the files - i.e. The user has a set of files,
but wants to *copy* them to a central location. The database stores
descriptions of the files and provides the only index to the location of the
copied files.

If it isn't in the database then
it doesn't qualify for downloading
and/or viewing. It doesn't matter if the
an image is sitting in folder... I have
images sitting in folders on my
webserver, you can't get them

This depends on the pattern implemented (1 or 2). If pattern (1) is
implemented, then there is no point storing the files in the database and
copying them needlessly. If pattern (2) is implemented, then there are both
advantages and disadvantages to storing within the database. Depending on
the requirements, the disadvantages may outweigh the advantages, or vise
versa. In any case, pattern (2) requires that the files be copied - if they
are stored in the database or on the server's file system doesn't matter to
the user - as far as they are concerned, they copied the file and the only
way to get to it is by querying the database.

Pattern (2) also requires that the database and files be kept in sync all
the time. If you're worried about deleting an image, but loosing the actual
image data, then you shouldn't delete the row from the database - simply
mark a "Deleted" field as true or something.

That's why I'm doubtful that storing
the 10K images directly in
the database is a good idea.
To be sure, it might be a great idea I just
(so far) don't think so.

It depends on the requirements and how you weigh up the pros and cons based
on those requirements.

I see now... it was intended to be an
invitation for discussion. Rather
than post "I think this... or that"
I thought I might find out what the guy
with problem had thought about so far.

*** I see that now, but your post could easily have been taken for one of
those 15 second answers (as I took it by mistake). Maybe a direct question
would have been better...

It isn't you Trev... it is the way people post
stuff in general.

It was partly me... I posted a response based on wide ranging assumptions.
That's another type of posting I'd like to see an end to.

That's one of the reasons
"which computer language is best" type
questions generate so
much heat and so little light.

lol. I never heard anybody put it better. We've all seen too many of those
posts lately (and I've always tried to narrow my answer down to "base your
choice on your requirements").


Thanks again for the discussion.


Take care,

Trev.

 

[Cor]

Hi Trev,

I would have been so lucky if Herfried would give an answer on this. )

But I am lucky with your answer anyway you understand, but why I did wanted
Herfried to answer was because of another reason. (He gives mostly greath
answers, but when it is about databases I told him he can better skip that a
while untill he real knows it).

My problem is, that I very good know how to get a Jpeg it a database, but I
want to cut those images also in a format that is more properiate for my
needs.

And I also heard Herfried saying that when you translate a gif to a bytearea
that you then lose half of your pixel information. (I believe that about
media Herfried knows it very well) And there is not alone Jpeg and Gif, so I
am in doubt if I gonna do that, so I stopped it a short while untill I see
some better documentation.

(On MSDN it is only in C# as far as I could see and very slight (encoding is
the keyword)).

I know very good how to put and get blobs in a database (Access, SQL
whatever) by the way.

It is the "correct" conversion from real quality images to Bitmaps and back
that botters me.

But a lot of thanks for your offer again, I remember it me when I start
again.

(I started with some greath help from Fergus, he gave me the start and then
I developped from that much further (not the database part, that I did know
already)).

Cor

 

[Trev Hunter]

No problem Cor. I thought it may have been a problem with the BLOBS. I
haven't got much experience with image conversion, so can't be of any use to
you. I would point you in the direction of
microsoft.public.dotnet.framework.drawing though...

Best of luck,

Trev.

 

[Herfried K. Wagner [MVP]]

It might but that would depend upon "deployment" and it wasn't mentioned.
Nor was the database.

If a solution is faster, easier and more reliable it seems like a good
reason to use it but I'm not certain we know that putting 10,000 images in a
database is any of those things.

It depends on the circumstances.

 

[Herfried K. Wagner [MVP]]

You know I am busy with this.

The trouble I have now.
I cannot convert all formats to and from the database.
I have the idea that I loose information converting it from and to

Can you help me to overcome this or tell me what is wrong or right of above?

Mhm... Why not store the files as BLOBs?