After We Shoot the Lawyers, We'll Shoot the Marketers

Before today, I was absolutely positively convinced that "LOB" stood for "large object base."

But I had a Jim Bakker moment when I ran across something that Torsten Schlabach wrote:

Some people are worried about the efficiency of storing large objects in databases and the implications on performance. They are not necessarily entirely wrong in fearing that storing large objects in databases might be problematic the best or might require a lot of tweaks to parameters in order to be able to handle the large objects. It all depends on how a database implements storing large objects.

Oracle comes with two completely different mechanisms for that:

1. LARGE objects
2. LOB objects

When comparing the LARGE datatypes such as (*fixme*) to the LOB datatypes such as CLOB, BLOB, NCLOB (*fixme*) they don't read that different at first. But there is a huge difference in how they are handled both internally inside the database as well when storing and retrieving from the database client....

A lot of non-Oracle-DBA people believe that LOB means "large OBject" because some other vendors have used the term BLOB for "Binary Large OBject" in their products. This is not only wrong but - even worse - misleading, because people are asking: "What's the difference between large and long?" (Bear with all non native English speakers here, please!)

Instead, LOB stands for Locator OBject which exactly describes what is is. It is a pointer to the place where the actual data itself is stored. This locator will need only occupy some bytes in the row thus not harming row size at all. So all the issues discussed above vanish immediatelly. For the sake of simplicity think of a LOB as a pointer to a file on the databases internal file system that stores the actual content of that field.

I was in the process of tagging information about LOBs, and since I try not to use acronyms in my del.icio.us tags, I was using the tag locatorobject for everything that I was tagging. Naturally, I extended this to related tags, for which I used terms such as binarylocatorobject.

But then I had a second Jim Bakker moment when I read something that James Starkey wrote on January 22, 1997:

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.).

Later that same year, Ann Harrison added the following synopsis:

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.

Just remember, Ann - marketing free doesn't pay.

(I'd show my duck picture, but Megacorp wouldn't like that.)



For more information

Sphere: Related Content