Back
Home
Up
Next

The true story of BLOBs.

    Thanks to Ivan Prenosil, I've get this piece of information that I only had partially. I decided to reproduce it in the original format. If you don't know who Ann Harrison and Jim Starkey are, you should read the history of Interbase to have an idea.

Date: Wed, 22 Jan 1997 17:22:26 -0500
>From: James Starkey <jas%harbor.com>
Subject: Re: Size of Image Blob Files

At 11:48 AM 1/22/97 -0500, Ann Harrison wrote:
>[snip]
>>InterBase stores BLObs in separate pages, with only the BLOb handle in the
>>parent record. This means that BLOb storage will never be totally in line
>>with the sizes of the images being stored. However, a 10:1 ratio seems 
>>beyond simple explanation...
>[snip]


Before we leave blobs, I would like to make something quite clear.
The rendering "BLOb" is an abomination! The fact that "Interbase" was
a company and "InterBase" was a product (or was it the other way around?
I never could keep them straight.) is bad enough. "BLOb" or "BLoB" or
"BlOb" is just too much. ArgggggggggggggH!

For the trivia inclined: Blob don't stand for nothin'. It isn't an
acronym for "basic large object" or "binary large object". A blob is
the thing that ate Cincinnatti, Cleveland, or whatever.

The precise chain of events that lead to the creation of the sublime
blob is:

1. Barry Rubinson, my boss at DEC, was prone to wandering around
muttering "blobs, blobs, we gotta have blobs." When I asked
what a blob was, he pointed out that I was the architect and
that was my job.

2. Marooned in Colorado Springs (where Barry lived) because of a
snow storm in Massachusetts (where I lived), and unable to
derive the grand theory of transaction consistency, I invented
the blob instead. Ah ha! A concept to hang on a wonder name!

3. The Rdb/VMS guys declared war on my sublime creation, the blob.
First, they argued, they never lost a sales because they didn't
have blobs. Second, documents and images didn't belong in databases;
that's what sequential files were for. Third, if you did want
to store a document, the right way to handle it was to normalize
the lines. [No, I'm not making this up. Ask Ann. She almost
never lies.] Finally, the term "blob" was unprofessional.

4. The retired bouncer hired to head the DSRI process rules that
blobs were in, but had to be renamed "segmented strings" to avoid
offending Clevelandites (or whatever).

5. Much later, Terry McKiever, an Apollo marketing gnome, fell in
love with the concept of blob, but felt the blob needed to be
an acronym. She started calling them "basic large objects." Apollo
never private labelled the product, so this should be irrelevant.
Unfortunately, her ravings got the attention of Informix (I think)
who announced that they would support "binary large objects" at some
future time. The damage was done.

6. Somebody asked a DEC product manager if and when Rdb/VMS would
support blobs. "Sometime in the future" was the "product guidance."
(The DEC, now Oracle, development group still know them as blob.).

7. Ashton Tate buys Interbase, Borland buys Ashton Tate. Some demented
Borland type styles the humble blob "BLOb". Jim gags.

I will respond to no mail containing the abominate "BLOb". If you want to
reply to this, excise the abominations first.

Bah!

Jim Starkey

====================
Date: Fri, 10 Oct 1997 10:06:24 -0400
>From: Ann Harrison <harrison@harbor.com>
Subject: RE: Blob history

At 09:47 PM 10/9/97 -0700, Jeff Davidson wrote:
>At 14:58 10/09/97 -0400, you wrote:
>>The term blob, as Jim would point out, is not an acronym for anything.
>
>It's not Binary Large OBject?

No, that was a marketing anti-acroynm invented after the fact because
somebody thought 'blob' was unprofessional. DEC called the same things
'segmented strings' for the same reason. At a conference some years 
later, a different marketing type was asked whether DEC had any plans
to support blobs. "Yes, in the next release, or cetainly the one after."
Fortunately somebody explained slowly and in short words that they
always had supported the concept, but rejected the name.

Thus endeth marketing bashing for today.

Ann

====================

Date: Thu, 9 Oct 1997 14:58:47 -0400
>From: Ann Harrison <harrison%harbor.com>
Subject: RE: Compressed Bitmaps

At 08:11 PM 10/7/97 -0400, Leyne, Sean wrote:

>I got a little confused on the SELECT performance penalties of Blob's by
>something said during a local Delphi/Interbase users group meeting. 
>Someone said that the SELECT processor would 'load' the contents of
>a Blob (as part of a record/row read) when processing un-indexed 
>criteria or when preparing the selected columns to be return to the 
>app,. SELECT Column FROM Table (keep in mind we're a Delphi shop, 
>so we use the wonderful/woeful BDE).

I can't tell you what favo[u]rs Delphi or BDE is doing for you, but
the intention of the blob was to allow storage in the database of
unstructured data too large to fit in memory. This was back when
memory cost money, but even today, not everyone can allocate 2 gig
buffers willy-nilly. Blobs were designed to be read a segment at
at time.

A bit of history. Blobs were invented at DEC by Jim Starkey and
first implemented in the Rdb products. When Jim designed InterBase,
he used the same mechanism, to wit: a blob-id stored in teh record
that could be openned and read immediately or cached and read later
(within the same transaction). Openning the blob creates a blob
handle, which is a pointer to a structure that includes the current
offset in the blob and allows the blob to be read in whatever size
chunks the program requests. [Segment size is advisory, not built-in
to the blob.]

The term blob, as Jim would point out, is not an acronym for anything.
He claims it's from the 1958 Steve McQueen movie. I always thought
it was a description of our boss, but to Jim's credit, if that was 
what he meant, he would have said so.

The only time that InterBase reads a blob on your behalf without
your openning it is when the blob is mentioned in your search
criteria (aka WHERE clause). Even then, the blob is just scanned,
not read into a buffer.

Best luck,

Ann

This page was last updated on 2000-10-17 02:32:09 -0400 .