Thursday, October 12, 2006

Death By Furniture

According to www.identifiers.org, there are two classes of relational database: "Code Class" and "Identifier Class".

We hadn't heard of those either, but it's all made clear in this presentation (pdf, 1.2MB), in which the limitations of the conventional approach and a novel approach to schema design are explained without the aid of Powerpoint, in a series of pictures like this one:

Still confused? Never mind, you can follow the debate on this OTN thread, which George begins by asking for a simple clarification regarding the capabilities of the Oracle RDBMS. From the answers to this, he should be able to determine whether Oracle is old-hat Code Class or funky new Identifier Class:

I have an interest in establishing how the Oracle System Catalogues cope with particular changes. I have never used Oracle, but I have carried out the same test on another RDBMS. If I had access to Oracle I would have carried out this test myself.

The test goes as follows.

Create a new database.

Create a new simple table, with just a few columns.

Create a form for the table, and add a few rows.

Rename the table or a column – if you can’t, then the RDBMS is Code Class.

If you can rename the table or a column, then do so, and invoke the form that you used before changing the table or column name. If it doesn’t work, the RDBMS is Code Class; if it does then the RDBMS is Identifier Class.

In an Identifier Class RDBMS changes of column or relation/table name will not interfere with the operation of any form already in place based on that table.

I'll be very grateful if anybody can give me a definitive answer on this, either through already having explored the issue or by running the test.

It turns out that "Code Class" covers all existing RDBMS products ever conceived, and "Identifier Class" is an improved model invented by George himself, in which some theoretical 4GL development tool yet to be designed allows you to change table and column names without breaking existing code or having to define a view, and surrogate keys are, well, pretty much the same except that they are now called attribute independent relative position independent identifiers. Perhaps one day Oracle will advance to this point, especially now that they've fixed DBMS_OUTPUT and must be wondering what to do next (perhaps after getting a product to work on Apple Mac and fixing the OTN "change password" facility). We can but dream.

15 comments:

Noons said...

Perfect! All it needs now is for Scott Ambler to click on to it and bingo:
the "next big thing" will be on and running!
.
.
.

Rab Boyce said...

Reminds me of intellectual impostures by Alan Sokal and the excellent postmodernism generator

well, I suppose it keeps him off the streets.

Anonymous said...

What I would like to know is how a form created against one identifier class database is going to work once we try to run it on another identifier class database (where the underlying table will presumably have a different identifier, since these identifiers are logically separate from the table and likely assigned by some internal database mechanism)? And if somehow you do have to specify the identifier anytime you create a table (to keep it the same from one database to the next) then it becomes synonymous with the table name (but harder to remember) and what has been gained?

Anonymous said...

Get away, they'll never port anything useful to Mac OSX.

Anonymous said...

And there's me wondering where my bloody hymn board had got to.

Rab Boyce said...

did George ever explain the mechanics of how this would actually work in a real world environment?

or was the explanation too horrible to behold?

Adrian said...

Well he left it at this, before disappearing into the ether, just like he arrived:

"It's a piece of cake. I don't know how you can see a problem. I cooperate with the RDBMS in a thoroughly effective way."

Anonymous said...

Did anyone actually manage to finish reading Georges Posts, I couldn't get past paragraph 2 of most of them without my brain starting to overheat. I couldn;t get the point, why create an identifier for a table to use in the application so you can rename the table? why have a name at all everything should just be table001, table002 .... table999.

William Robertson said...

> Bishop of the Diocese Oxford said...
> And there's me wondering where my bloody hymn board had got to.


As a test, please try renumbering all the hymn books during a service. If you can do so without causing disruption, then Christianity is an Identifier Class religion.

Anonymous said...

I couldn't get past paragraph 2 of most of them without my brain starting to overheat.

Yep. We have, indeed, discovered the Dr. Bronner of the RDBMS engineering world. Airpii, Airpii, OK!

roselan said...

will be very fun for 'text' sql like execute immediates or jobs.

Then I need to compile an old proc again, do you think the db will look in the ddl history and auto-update my my code?

l33t ^^

Anonymous said...

And how RDBMS "identifier class" can identifies database elements .. ah, of course.. unique identifiers ?? ..

a little complicated theory ...

In other words you always could change the identifier...

William Robertson said...

Well clearly a lot of it gets taken by database theorists for presentation materials.

Anonymous said...

I notice he doesn't have an blue tooth earpiece in the photo.

Do you think he's wearing one in the other ear?

William Robertson said...

If he'd improvised one out of discarded hospital furniture I think we would see it.