Readers have probably noticed that I was a DBA (Database Administrator) in a former life and I'm an enthusiast for the Relational Model. However, I must confess that I've always taken my Codd re-digested by Chris Date (I have two editions of his work An Introduction to Database Systems on my shelves, both of which I actually …
I saw Hugh Darwen give a presentation last year on the history of SQL, the problem with NULL, and Tutorial-D. It was fairly enlightening, even if I found myself sceptical as to it's practicality.
As I understood it, one of the problems they see with NULL is that it fails to distinguish between 'information unknown' and 'does not have a' - or rather than the semantic meaning of the NULL value is held in the code that deals with the NULL value, rather than understandable from the schema.
The solution proposed wouldn't work with modern RDBMS - seemed to involve denormalising every NULLable column off into it's own table, but it's only our experience of RDBMS performance that makes us think this is such a bad idea.
I think a lot of the concepts in Tutorial-D would help close the supposed 'Object-Relational' mismatch - it seems to have a closer fit to the notion of inheritance.
But overall, I share your pessimism - the reality is that there is a generation of 'database hostile' programmers out there, who would rather pull back thousands of rows up into an OO language, modify them using an iterator, and push them all back to the database layer, than use a set based update statement.
(Equally I think it is little appreciated how much relational theory stands on top of very solid mathematical foundations, far more so than the heuristic approach of object modelling. Then again, consider the success of mathematically sound formal languages against the programming languages that have been succesful).
Depends what you mean by success
>it is little appreciated how much relational theory stands on top of very solid mathematical foundations, far more so than the heuristic approach of object modelling. Then again, consider the success of mathematically sound formal languages against the programming languages that have been succesful.
Well, I certainly agree with the first part of that statement. As for the second part, it really does depend on how you define success. Praxis points out that although the "mathematically sound formal language" Spark probably isn't as popular as C#, say, Praxis is still in business and still has important customers (such as the NSA) that choose Spark in preference to other languages - for safety critical (and other) projects, where defects simply aren't tolerated. That's a sort of success.
The trouble is, I haven't met a "mathematically sound formal" relational database recently, so I don't know if it would be successful. I don't even think that one has been tried in commercial practice (at least since memory and CPU constraints have been relaxed) and found wanting.
Oracle, DB2 and SQL Server are very good databases, just as IMS (which was my area of expertise once) is a very good database, but they are all more or less "heuristic" databases; and perhaps a "true" relational database with a proper optimiser would support a leap forward in system reliability and ease of programming.
- Review This is why we CAN have nice things: Samsung Galaxy Alpha
- Hey, YouTube lovers! How about you pay us, we start paying for STUFF? - Google
- MEN: For pity's sake SLEEP with LOTS of WOMEN - and avoid Prostate Cancer
- Vid BONFIRE of the MEGA-BUCKS: $200m+ BURNED in SECONDS in Antares launch blast
- Tim Cook: The classic iPod HAD to DIE, and this is WHY