Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

To Blob or not to Blob

Status
Not open for further replies.

NeilTrain

Programmer
May 27, 2003
275
US
That is the Question...

So we are developing a new version of our application, to replace one developed way back in the ancient days of computers (1996)

The currently running version is a wonderful tool, however it is a dog, it is hard coded to use interbase (blech!) as its back end. It gets bloated and slow, and forces us to copy it to a new server for different websites (we have several websites using this app).

We believe a new version developed with a SQL 2k5 backend will allow us to consolidate all our sluggish interbase servers into one silky smooth beast of a database, however, in an attempt to plan out the best possible setup for performance, we are not sure wether to use blobs, or to store them in the filesystem.

Our application can pull anywhere from 3 to 12 image files every time it is called. It then runs some whacky graphics routines on these images, and returns one finished image to the calling process.

Our current setup has a total of about 100,000 images, all stored as blobs in the interbase databases.

My question is, would there be any performance benifits to keeping all the images in blobs? and if so would it be a good idea to keep the processing code on the same server to cut down on the network bottleneck?

What are the drawbacks to working with a lot of blobs?
 
Over here I have a lot of images to and we also need 3 or more at the same time.

And we keep them in the file system for different reasons. One being that you could easily manipulate them as files another benefit is that they should take less HD space and ... .
And we store them on a seperate server wich makes them load faster.

And of course there are drawbacks. What if path and image don't correspond? What if the fileserver is down? What if you run out of coffee?

But it's all a matter of opinion.

Christiaan Baes
Belgium

"My new site" - Me
 
> What if you run out of coffee?

How true.

The Suits always talk about stronger iron, scan-your-eyeballs security, transwarp enterprise & blah solutions, while the most important piece of hardware in every serious IT system is - poor forgotten coffee machine. Double with no sugar please...

Regarding images (picture files), I'm all for keeping 'em on filesystem. With doc/pdf stuff - things would be maybe different, dunno.

------
"There's a man... He's bald and wears a short-sleeved shirt, and somehow he's very important to me. I think his name is Homer."
(Jack O'Neill, Stargate)
[banghead]
 
I would not store them in a DB, just the filepath
reason 1 backups are much smaller (no GBs of image data)
reason 2 security, someone steals your DB, the person has all your data + the images (all he needs basically)

my 2 cents

Denis The SQL Menace
SQL blog:
Personal Blog:
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top