Blogging about Blobs, Backronyms and the Birth of a Relational DBMS

Thu, 31 Jan 2008 15:44:57 GMT

A valued colleague of mine, David Waxberg, sent me a link to a discussion on the history of the term blob. I had always understood that BLOB stood for Binary Large Object. According to some database pioneers, this just isn't the case.

According to Ann Harrison and Jim Starkey (who developed Interbase), the term blob started out as more of a yadda, yadda, yadda type phrase that was used to describe a new DBMS concept. Marketing and management, though, felt that they could not use the term blob and called the functionality segmented strings. Then marketing accepted the term blob, but did not want to say that it was just a filler term conscripted to be a serious DBMS functionality, so they came up with Basic Large Object as the meaning, turning blob into a backronym.

Then the Informix guys used the same concepts and described a blob as a Binary Large Object, yet another backcronym.

" 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!"

Now you know more about BLOBs than you did before.

Look for my next post on the birth of a relational DBMS...

Karen Lopez: Musings on Data, Process, and Architecture

Blogging about Blobs, Backronyms and the Birth of a Relational DBMS