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

>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 Received on Wed May 07 1997 - 00:00:00 CDT