Time For the Cattle Prod [update]

The transition to Organic Normal Form™, propelled by MultiProcessor/Core/Thread/SSD, hasn't been as seamless as I've hoped/predicted. More like Rory McIlroy's recent golf game. Ah well. But the truth will out, in truth.

Since I'm not a MS sort of guy for some time, I'm only recently aware of Hekaton. Boy howdy! Now, not by any means the first in-memory engine (or partial engine) from an industrial strength RDBMS (TimesTen/Oracle, SAP/HANA, and solidDB/IBM come to mind), but SS does serve a larger population of installs (that's speculative, since sources such as IDC charge a pretty penny for their data, although "According to Microsoft officials, 46 percent of the databases deployed worldwide are now SQL Server, and customers are running 300,000 SQL Azure databases in Windows Azure" [here]). The point, of course, is that if SS goes in-memory, the pressure to normalize goes up a tad, what with all those SMB OLTP systems (existing and under development) that benefit from minimum footprint supplemented by joins. This could be the straw and camel moment.

Here's hoping.

Here's a Microsoft Research page. While it doesn't push the normal form benefits of Hekaton, just have a look at that pix of the developers. THEY'RE OLD FARTS!!!!! Take that, Kiddie Koders. It generally helps one in making something that is truly new to know what, exactly, was the Olde Stuffe. Had the Kiddies paid attention, we might have been spared all things xml and NoSql. ISM/VSAM variants to the hilt.

"We had an 'aha' moment," Lomet recalls, "when we realized that a single table that maps page identifiers to page locations would enable both latch-free page updating and log-structured page storage on flash memory. The other highlight, of course, was when we got back performance results that were stunningly good."

Here's a hot off the presses report. Read it, and lick your chops. Note that FK constraints (but doesn't say whether FK can be defined for access path purposes; yes, there already exist RDMBS engines* that support such an option) aren't yet supported.

Or, as one of Red Gate's (my favorite SS/RDBMS site) bloggers put it:

My biggest disappointment with the initial version is that it does not support foreign key constraints or check constraints. For a database designer/developer, "let the application handle data quality" is like fingernails on a chalkboard.

Nice to know that some people vote for Abbie Normal.

So, half a loaf. But, I strongly suspect that FKs will show up soon enough; if only to have a sensible OLTP engine. After all, an RDBMS targeted for OLTP, as MicroSoft states, can't be truly serious without that.

Hmm. SSD to support buffer pools? I have to finally admit defeat and run Windows?? While I've always had a hankering for SS, I just can't abide Windows. Scylla and Charybdis.

[update]
* Informational constraints tell the database manager what rules the data conforms to, but the rules are not enforced by the database manager. However, this information can be used by the DB2® optimizer and could result in better performance of SQL queries.

here