Re: When not to use a DB? (Was: Re: What DB to use for lots of IMAGE files?)

Chao Y. Din wrote:
>
> >Jim Reynolds <reynolds_at_ece.vill.edu> wrote:
> >
> >> Chao Y. Din <cdin_at_explorer.csc.com> wrote:
 

> >>You must have estimated images size with a specific image format. Which
> >>format is your estimate based upon? Are you using color images? Are
> >>you planning to use BLOB? We are using Informix on SPARCs and all
> >>images are stored as BLOBs.
> >
> >Dare I ask the question...
> >
> > Why would you want to store images in a database to begin with?
> >
> >Seems to me like it would be better just to store the filename of the
> >image in the database, and when it's needed by the application just load
> >it in from disk.
> >
> >What does putting graphics/sound/video into a database like Informix
> >buy you? Seems more limiting than anything else-- you need custom
> >applications to access and make use of the data; more errorprone in the
> >sense one misplaced bit could cause an entire data file to be lost
> >which presumably contains lots of images, as opposed to a single image
> >file getting corrupted; you can't look at the data if the DB is down.
> >
>
> Jim,
>
> There are many reasons why we decided to use BLOBs instead of files. We
> did exprienced many disasters in the past four years of development,
> major and minor. Yet we always found that images were protected by the
> transaction process of the database -- bad images were always rolled
> back. In order to provide the same kind of protection for files, you
> must buy Tuxedo and write C code to interface with Tuxedo and operating
> systems -- more error-prone and costly.
>
> You listed two reasons not to use BLOBs -- BLOBs require customized code
> and more code invites errors. First of all, our project is so huge that
> you cannot find a single imaging COTS that meets all the required
> functionality. We need customized imaging software regardless whether
> images are in BLOBs or files. The question is then whether BLOBs is
> more complicated than files. The answer is no. Once we figured out how
> to (1) load images from files to database, and (2) scan images directly
> into database, the rest is easy. In fact, the code for image
> manipulation is much less complicated than files. For example, a set of
> image FILES must be modified based upon data in the database. Some
> image FILES have been changed successfully, yet the next change fails.
> Since those image FILES are all belongs to the same record, how do you
> maintain the integrity of the record?
>
> As to error-prone, I am not sure what kind of programmers you have been
> dealing with. For most projects, I probably would recommend using
> COTS. But when it comes to a mission critical project, like the one we
> are currently working on, I must recommend to avoid COTS. I believe it
> is a myth that COTS is always a better solution.
>
> Our client (a government agency) was sued several years ago because of
> mis-handling some microfiches. The images we are dealing with affect
> people's career. Furthermore, the images we processed will be sent to
> National Archive Center where the images will be kept forever. Due to
> those reasons and fear of being sued, we decided to use BLOBs.
>
> In fact, we do have three sub-systems that must use image files: OCR,
> microfiche scanner, and HSM. No OCR packages support BLOBs, no
> microfiche scanner and the associated software packages handles BLOBs,
> and all HSM packages have limited support on BLOBs. We did not have
> time to develop our own OCR and microfiche scanner software. We cannot
> imagine to spend time on developing HSM. Guess where most failures
> happen? OCR and microfiche scanner. Because both are handled by COTS,
> our client can never blame the problem on us.
>
> Let me re-phrase your last question:
>
> Why do you want to use DB to store images? You cannot access the
> images if the database is down.
> Why do you want to use non-ascii files to handle your word processing?
> You cannot access the file if the word processor is down or corrupted.
> Why do you want to use computer to begin with? You cannot access your
> data, your program, your ... if the computer is down.
>
> I cannot answer such questions. I guess I don't understand the rush to
> "computerization" and such?
>
> >So, why the rush to "relationalize" images and such?
> >
> >Someone, enlighten me. :-)
> >
>
> I believe a hidden issue here is whether you can maintain data/image
> integrity between database and operating system files. If you believe
> you can accomplish data/image integrity by using database and files at
> the same time, please enlighten me.
>
> Chao Din

There are some bizarre arguements mentioned here for not using a database and you counter them rather well. A database is probably the most secure and stable place that you could store your data, any data.

We used LEADTOOLS to compress/uncompress images before saving them in the database and after retrieving them. It worked very well with SqlWindows and Oracle 7.x and the product isn't specifically designed for either one. You can use it with any language that can call a DLL.

Heck, if this guy is so paranoid about losing data, why not just keep it all in hardcopy format<g>?

Like any repository of importance, regardless of the media (paper, disk etc.), if the material is important enough, then safeguards must be built into the design, and in this case you're looking at backups and UPS devices as a minimum. The fault tolerance issues rise from there.

Then again, competent programmers and designers are also a big part of the equation.

-- 
Steven Fundarek
Sfware Consulting Inc.
sfware_at_idirect.com

*** Please do not e-mail replies directly to the posting ID 
as it cannot receive incoming mail.

Responses either via the newsgroup or to me via sfware_at_idirect.com are
appreciated.
Sorry for any inconvenience on your part.