[RESOLVED] Experienced Programmers - Question

[chris.cavage]

Here is my question to those who can relate:

I have heard over and over again to NOT store pictures in a blob on a server, because it can bog down the server in a hurry if many users are using the application.

But.. how does this really come into play? If I have 500 images on my server, will that bog it down? Will it only be a problem if say, under 10 people, are accessing the server at once?

Can someone put this into a real-world example? Thanks!!

[RhinoBull]

How large are the images (or at least what's the avg size) and how often do you need to extract?
More efficient way of course (and by far) is to store pointer (path) to actual file.

[techgnome]

it also depends on what the images are and for what. Is this a web app? or is it for a windows app? are we talking about images that are in the Megs big? Or are we talking about Icons?

-tg

[chris.cavage]

this is a windows application that will create the image and then store it on an online server to view the image from home.

average gif size is 22 kb.

[RhinoBull]

I would just store image path in the database - 20 KB is not munch at all, however it would d still require some time to extract image regardless of methodology (extracting to a file or converting on-the-fly).
On the other hand getting image from the hard drive could be almost instantaneous.
Btw, if there is a value then your images may need to be copyrighted with appropriate and distinct message for those who will be viewing.

[chris.cavage]

thanks Rhino. With my specific application, the image from the windows application *needs* to go on an online server.

I hesitate to reference the image path online, because of how confidential the image is, if viewed by someone else.

Hence my concern for a bogged down server with these blobs. I wonder how bogged down the server can really get? I would like to plan ahead of time, that's all.

[RhinoBull]

Benchmarking partially depends on hardware - we have multi server cluster that handles hundreds of simultaneous users without any problem what so ever.
We store only pointers to images and video (true hd files) so streaming is extremly fast - I can't imagine what would it be to store thos large files directly in db.
It would probably double the cpu usage I think but best way to find out is to actually clock server cpu while dozen of users try to access it.
IMHO it's never about "best practices" but rather "what's working best under sircumstances".

btw, if you need some sample code to save/extract file there are few links in my signature.

[chris.cavage]

thanks a lot.

i seems trial and error is best, right? ;-)

from what i gather, i have a decent shot at not having it too bogged down because the file size is so small.

i doubt anymore than 12 people will use this at one time too.

[si_the_geek]

Thread moved to Database Development forum (the "VB6" forum is meant for questions which don't fit in more specific forums - and for this question the programming language is almost irrelevant)

It should be fine to store them in the database - one of my systems (using SQL Server 2000) stored many more pictures than that (and larger too), with lots more users, and there were no speed issues. However, the effects it has depends on the design of your system.

Assuming that the pictures would otherwise be stored on the same server, the difference between storing the pictures in the database or file system is negligible - either way the disk is accessed and the data transferred, the biggest difference is that the database system will take slightly longer to find the 'file' to start with (and that will probably only add a few milliseconds per picture).

[szlamany]

Store them in the database.

That creates a single-suitcase for encapsulating your data that helps in disaster recovery, for instance.

We have one client storing nearly 10,000 student pictures in a DB.

It's even a more secure place to store them - right?

select sum(1),sum(imagesize) from stuphoto_t

----------- ----------- 
9712        253859296

(1 row(s) affected)

We were actually driven to do this by the fact that we have pocket pc's that gather the images from the database during a sync operation we have. And the easiest way for a PPC to talk to a network resource is through a database connection.

Remember - regardless of where the object is stored it still needs to come from somewhere and go through some pipe to get to your client app. Personally I see no difference in having the DB serve it to me. If I had more time I could benchmark this - but who has time...

[FunkyDexter]

Personally I'd go with storing them in the DB for two reason.
1. If you store them separately on disk your application code has to cope with orphaned references (ie some numpty has deleted the image file but the DB hasn't been updated to reflect the fact that there is no image)
2. If you store the image on disk then you need to open up access to the disk to your application. Your application already has access to the DB server so why open up a second hole?

[RhinoBull]

For those of you "preaching" for storing images in db here is something to consider:

- blobs degrade db performance
- due to rapidly increasing size (when files are added frequently) backups may take longer with chance of failure
- it's resonable up to certain size
- absolutely not acceptible for storing movies [imho]

... list can go on and on ... however there is no definitive "yes" or "no" - plenty of pros and cons for either approach so as I said lots of testing has to be done before making decision.

[RhinoBull]

Btw, you also need to consider DR (data recovery).
DRs are usually done somewhere off site with network and hardware configuration all being far from their production cousins.
So, attempt to stream live data from db may never reach the client...

[chris.cavage]

I will look into this.. Thanks!