Recovered from the Wayback Machine.
This alternative, known as ‘Tutorial D’, would seek to eliminate some of the more persistent relational DB problems, such as that pesky multi-meaning null. Is a field null because it makes no sense for data to exist in the field? Or is it null because no data has been provided yet? This has always been a killer in database design, and something the proponents of “Tutorial D” could resolve, among other things.
But before we throw out our MySQL and Oracle, the authors caution, take heed:
There’s a way to go, though. First off, there are still some unconquered faces on the mountain – the notes from a presentation by Darwen (see the Third Manifesto website) admit that the implementation of some of the new techniques is “something for the next generation of software engineers to grapple with”. The main problem, however, is that although SQL is clunky and, from a purist’s standpoint, just plain messy, it passes the usual business test – that is, it’s good enough to do the job that’s asked for it.
SQL is ubiquitous. For something that’s weak, fallible, and failing, it’s used everywhere; it’s a rare application that doesn’t use a relational database. This is something the ’s, w’ semantic webbers, (not to mention the RDF critics) should keep in mind: a technology, a model, or an implementation doesn’t have to be perfect to be useful.