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

At 11:48 AM 1/22/97 -0500, Ann Harrison wrote:
>>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...

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.


Jim Starkey

Date: Fri, 10 Oct 1997 10:06:24 -0400
>From: Ann Harrison <>
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.


Date: Thu, 9 Oct 1997 14:58:47 -0400
>From: Ann Harrison <>
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 the 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

Like this post? Share on: TwitterFacebookEmail

Related Articles


Jim Starkey

Ann Harrison