06 October 2010

I Hear You Wanna be A RAP Star

The intent of this endeavor has always been to demonstrate that the relational model, when implemented in a BCNF database, is not only the most efficient storage model, but also the most robust.  One of the side effects of BCNF databases is that they are ideal for code generation.  After all, catalogs are simply plain text (and with none of the noise level of xml) and thus sources for text munging. 

Today another code generation framework came by.  While it doesn't make any BCNF claims (that I can find, at least) nor does it promote SSD as appropriate to its implementation, both fit precisely.

Here's the web site and over here is a White Paper describing the use of the system.  Since it's not only SQL Server but also implemented as a Visual Studio project, and I'm on linux only, I've no way to test it.  I've gone through the White Paper, and it does look interesting.  I will note that the silliness of naming all tables with a prepended "TB" is a tic we should all have outgrown by now. 

There isn't any mention of parsing of either check constraints or stored procedures in the generation of the UI.  The check constraint bit shouldn't be any more difficult than the foreign key business, although the stored procedure wouldn't be a walk in the park.  With a BCNF catalog, one could define lookup tables as real tables as foreign key targets.  An SSD stored database would make that same, same.  For that matter, using a database such as DB2, where one can define separate tablespaces/bufferpools, such (I'll assume small) lookups won't be heavily modified and can be assigned to a dedicated bufferpool of sufficient size that none of the rows will be evicted.  Done, go home.

No comments: