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