Friday, May 24, 2013

The fRiDaY File - Screech!

Screech! That's the sound of me hitting this sentence in the middle of an otherwise excellent article about SAP's recent Sapphire conference:

"The transport mechanism for this is a HANA cloud platform that allows the software’s data calls to go through HANA instead of a relational data base."

Whoa, hold on there sonny!

HANA is a relational database system. It has other stuff too (a graph engine and a text engine) but the big deal is its super-fast in-memory row- and column-oriented relational engine.

Maybe the author should have said "instead of a traditional relational data base" or a "disk-oriented relational data base" or a "legacy DBMS", something like that.

But no, I think the author really does think
  • that HANA is different from relational,

  • that relational implies row-oriented,

  • that column-oriented does not qualify as relational, and

  • that in-memory is somehow not relational.
If he doesn't think that, certainly lots of other people do.

Not true!

One of Codd's 12 rules for relational database management systems is this:

Rule 8: Physical data independence: Changes to the physical level (how the data is stored, whether in arrays or linked lists etc.) must not require a change to an application based on the structure.
That means it's perfectly OK, even encouraged, to have a variety of different physical architectures just as long as those architectures and the differences between them don't affect application code.

And THAT means HANA can be called a relational database even when it uses a column-oriented store, as long as Rule 8 and the others hold.

Another thing: HANA has BOTH row- and column-oriented tables. In fact, if you code CREATE TABLE in HANA you get row-based storage; to get column-based you have to ask for it by coding CREATE COLUMN TABLE.

Pedants might say having to code CREATE COLUMN TABLE violates Rule 8 because it requires a change to application code. Pedants might also say that not one single commercial product qualifies as "relational" because there are many ways physical characteristics bubble up into the code; think query hints.

In the real world pedants live at home in their parents' basement and have no effect on the fact SQL Anywhere, SQL Server etcetera are all recognized as relational...

...and HANA as well.

No comments: