Wirt is absolutely right.

My experience with Blob support in relational databases has NOT been a
happy one.
Perhaps I expected too much.

My client scans and stores medical claims (10,000 to 16,000 per day) as
200dpi .tiff files.
In 1991, we installed HP Aims, an imaging system from Hewlett-Packard
based on bought in technology.
The underlying structure was Informix on an HP9000, with Plexus (or
Recognition Systems) C libraries to handle scanning, indexing, Windows
4GL programming etc.

It quickly became apparent that blob support in Informix was an
desperate Add-On (Version 1.0), and it quickly became apparent that we
could have done it better ourselves.

Having said that, I must say that for all it's annoyances, it NEVER lost
a single image - just hours and days of my life nursing it along.
Also, with each release of the AIMS system, things got a little better.

Then HP dropped support for AIMS, pointed us at Recognition UK, and
basically left us on our own.

Finally, we developed (with the benefit of hindsight) our own system,
based on the same hardware (except NT instead of UNIX), and very much
more open systems.

The client (and another) still scans 10,000 to 16,000 200dpi .tiff files
per day, but they are stored on an NT server (100mhz Pentium HP
Netserver) with 150GB or RAID as actual files. Each is given a serial
number and these are "slashed" into a hierarchy of directories, so for
instance serial number 10000003.tif lives in \00\10\00\00\03.tif, and
it's neighbour might be \00\10\00\00\02.doc, or \00\10\00\00\04.xls.

The serial number is the only entry in the TurboImage database.
This makes it easy to "Image enable" any existing or new application.

We glue the structured data (from the HP3000) and the blob from the NT
server together on the client (PC running Windows) using a Visual Basic
DDE capable viewer, and Reflections via DDE commands echoed from the
HP3000 - that's how we acquire images too BTW.

Works well, lasts a thousand years etc. etc.

That's why I'm so happy with Lars' efforts to port Samba/iX to the
HP3000, because now the possibility exists to scan, store and retrieve
these images onto and from the HP3000!

IMHO, the minute you use a single Stored Procedure, Trigger, or other
Rule in the modern SQL databases, you are locked into that single RDBMS.
As far as I know, there are absolutely NO standards for triggers, stored
procedures, rules across RDBMS's.

I would advise that the DBMS be used to store and regurgitate data, and
that ALL algorithms are written and maintained in a language of your
choice.

Think how easy it would be to migrate (heaven forbid) your TurboImage
application to flat files, KSAM/CISAM files, or another DBMS. Terribly
simple!

Just late night thoughts :)

Regards

Neil Harvey



> -----Original Message-----
> From: HP-3000 Systems Discussion [SMTP:[log in to unmask]] On
> Behalf Of Wirt Atmar
> Sent: Sunday, March 16, 1997 9:36 PM
> To:   [log in to unmask]
> Subject:      Re: BLOB data in a TurboIMAGE database?
>
> Paul Krikorian asks:
>
> > Does anyone know if it is possilbe to store Allbase BLOB type data
> in a
> >  TurboIMAGE database, and if so, what are the storage limits of a
> single
> >  BLOB?  This concerns a new ID card system where we might have the
> option
> >  of storing the student's picture with the textual part of their ID
> card
> >  data.
>
> The answer, at the moment, is no, it's not possible to store BLOBs in
> IMAGE,
> although BLOB manipulation has been slowly moving up on the SIGIMAGE
> improvement ballot over the past five years (it's currently something
> like
> fourth place now), which indicates increased recognition of the value
> of
> BLOBs among the voting members.
>
> (BTW, the SIGIMAGE group maintains strict admission requirements for
> membership into SIGIMAGE. The requirements are: you must be a
> bilaterally
> symmetric, bipedally upright hominid, capable of grunting at the
> proper times
> during the voting process. If you meet these stringent criteria, this
> prestigous group would be honored to have you join them).
>
> However, something I feel quite strongly about is that BLOBs shouldn't
> be
> done in the same manner as they are done in ALLBASE (or almost all
> other
> RDBMSs). In ALLBASE, the BLOB is held in-line with the other fields --
> and I
> believe that doing this will become more and more obviously considered
> to be
> a fundamental design mistake, simply because BLOB usage is likely to
> increase
> quite explosively once desktop presentation mechanisms become common.
>
> BLOBs grew out of a philosophical extension of variable character text
> in
> RDBMSs, where text fields are the most general form of data storage in
> computers. You can store either a variable amount of text in such a
> field (as
> was the original intention) -- or you can store a bit-mapped
> signature, a bit
> of Beethoven, or a full-length, high-resolution, quadraphonic sound
> copy of
> Dr. Zhivago, the movie.
>
> And that's the essence of the problem: all of the BLOB material stored
> in
> this manner has to be backed up because it is an integral part of the
> database. But BLOBs will never as dynamic a part of the information
> held in
> the database's fields as are the more normal fields (name, address,
> city,
> ....).
>
> By far and away the best way to design BLOBs into IMAGE is to create a
> blob
> object manager and store the BLOBs orthogonally to the data. This is
> not as
> difficult as it might sound. In fact, almost any of us could do it in
> a
> weekend. Presume that your BLOB object manager/storage mechanism was
> nothing
> more than a studio-quality DVD disc with high-speed indexing. In order
> to
> modify IMAGE to make it BLOB-capable, all you would have to do in add
> two or
> three new dataitems to the record: start point, stop point, and some
> form of
> disc ID name and provide some mechanism to pass that information to
> the DVD
> player.
>
> If you then wished to see a particular sequence of Dr. Zhivago (or get
> a
> signature, or a scan of a check, or whatever), you would search the
> IMAGE
> database as you always have in the past. Once the appropriate
> record(s) were
> found, the information held in the start, stop and ID fields would
> then be
> retrieved, passed to the BLOB object manager (which could be as simple
> as a
> small file reader program, where the data is stored on your standard
> discs,
> or a complicated as an automated disc retrieval system), and have the
> resulting bit map stream passed back to your desktop device for
> presentation.
>
> The structure of IMAGE in this design would be more like the index
> that
> appears at the end of a textbook. The index is the IMAGE database. The
> pages
> of the book are orthogonal BLOBs. If you wished to read every page in
> the
> book that had something to do with subject X, you would search the
> index as
> you always had and then retrieve only those pages of interest.
>
> The advantages of this form of design is that IMAGE remains small and
> compact, thus easily backupable, and very fast in retrievals, while
> the
> nature of the BLOBs are free to evolve as necessary, almost without
> impact on
> the fundamental nature of IMAGE or the CPU that bears it.
>
> Wirt Atmar