December 12, 2015

Abstract datatypes and extensible RDBMS

In my recent Stonebraker-oriented post about database theory and practice over the decades, I wrote

I used to overrate the importance of abstract datatypes, in large part due to Mike’s influence. I got over it. He should too. They’re useful, to the point of being a checklist item, but not a game-changer. A big part of the problem is [that] different parts of a versatile DBMS would prefer to do different things with memory.

and then left an IOU for a survey of abstract datatypes/RDBMS extensibility. Let’s get to it.

Perhaps the most popular term was actually object/relational DBMS, but I’ve never understood the etymolygy on that one.

Although I call RDBMS extensibility a “checklist item”, the list of products that can check it off is actually pretty short.

Surely there are more, but at the moment I can’t really think of which they are.

As you might think, the point of abstract datatype/extensible DBMS technology is a way for a DBMS to be extended to handle more datatypes, via something called a datablade (Illustra/Informix), cartridge (Oracle), or extender (DB2). Obviously, support has to be top-to-bottom, including in the DBMS’ parser, optimizer/query planner, etc. But the real issues usually lie in the access method — i.e., how data of the new datatype actually gets in and out of storage — and most particularly including indexes and the in-memory parts of query execution.

Notes on adoption start:

The problem, in a nutshell, is that there’s a huge difference between making database technology sort of work and making it work really well, and datatype extensions typically get stuck in that muddled middle. One problem, as I mentioned above, is memory management. Another is getting any kind of decent cost estimate into the optimizer. A third is that the general RDBMS may just generally drag along a lot of overhead that a more specialized datatype-specific store might not need to deal with.

Beyond what I’ve already said, notes on the commercialization of RDBMS extension technology include:

And that’s where I’ll leave it for now. If I post some day on the history of search, or with more detail on 1990s RDBMS competition, I may return to the subject at that time.

Comments

4 Responses to “Abstract datatypes and extensible RDBMS”

  1. Readings in Database Systems | DBMS 2 : DataBase Management System Services on December 12th, 2015 6:54 am

    […] Edit: As promised, I’ve now posted about the object-relational/abstract datatype boom of the 1990s. […]

  2. Introduction to SequoiaDB and SequoiaCM | DBMS 2 : DataBase Management System Services on March 12th, 2017 1:20 pm

    […] Triggers and referential integrity are not. Neither, so far as I can tell, are PostgreSQL’s datatype extensibility […]

  3. Introduction to SequoiaDB and SequoiaCM – Iot Portal on March 12th, 2017 6:33 pm

    […] Triggers and referential integrity are not. Neither, so far as I can tell, are PostgreSQL’s datatype extensibility […]

  4. Introduction to SequoiaDB and SequoiaCM – Cloud Data Architect on March 17th, 2017 7:45 am

    […] Triggers and referential integrity are not. Neither, so far as I can tell, are PostgreSQL’s datatype extensibility […]

Leave a Reply




Feed including blog about software history Subscribe to the Monash Research feed via RSS or email:

Login

Search our blogs and white papers

Monash Research blogs

User consulting

Building a short list? Refining your strategic plan? We can help.

Vendor advisory

We tell vendors what's happening -- and, more important, what they should do about it.

Monash Research highlights

Learn about white papers, webcasts, and blog highlights, by RSS or email.