Most people who use databases in anger are familiar with the concept of a relational database. The idea of "normalising" data in order to minimise duplication of information, whilst providing a mechanism to "join" the disparate data collections together based on common fields, is well understood even by relative newcomers to database technology.

Relational databases as we know them today are, however, far from optimal – at more than one level. At the lowest level we have the database implementation itself – not least the fact that as well as containing elements of information, fields are also permitted to be empty, or "null". And then there's the language that we use to insert and extract data – SQL, or the Structured Query Language: it's relatively simple to learn, but the syntax is often inconsistent and unless you use one of the many vendor-specific supersets of SQL it can be tricky to express complex series of operations in a concise manner.

It should come as no surprise, then, that work has been going on for some years to devise a more correct alternative to the relational database as we know it today. Perhaps the most promising is the work done by a world-renowned pair of database specialists, Hugh Darwen and Chris Date. The former is a retired IBM database specialist, and the latter is the author of the standard text book on the subject used by most good universities and colleges to teach database-oriented subjects. Darwen and Date, in their book Foundation for Future Database Systems: The Third Manifesto (ISBN 0201709287), take a step back at the way databases work and describe a new approach to database architecture.

Given that Darwen and Date's book is a couple of years old now, why are we suddenly interested? Well, in the last few days university lecturer Dave Voorhis has announced the launch of his implementation by of a database language called Tutorial D; the latter is a language designed by Darwen and Date as the interface to their new database architecture.

So what's the big deal? In a nutshell, Tutorial D is intended to be a "proper" implementation of a database query language. The idea is that there should be no arbitrary restrictions on the syntax of the query language (Voorhis cites SQL's rather arbitrary habit of allowing nested queries in some places but not others, for instance), but at a lower level the database shouldn't run up against idiotic limitations. The limitation in existing implementations that generates the most comment from the various parties in the debate is the problem with "null" values in relational databases. Put simply, a database field has a type (50 characters, for instance, or a floating point number to two decimal places, or an 8-bit integer), but when you don't fill the field in (i.e. it's "null") it loses all its meaning. Even the ANSI standards state that if a field is null it's said not to exist – so if you ask a database for "all entries where field X is not equal to 47" it won't return any of those where field X is null because instead of saying "Null doesn't equal 47", the value "null" is deemed not to be comparable with any non-null field.

Darwen and Date's new architecture addresses many of the limitations of today's relational database structures – not least the ever-present issue of "null" fields. It talks about new techniques for normalising data which eliminate problems, though unsurprisingly the elimination of some gotchas has brought about the need to introduce some new concepts to make the model work successfully. And in many ways, the new structure (and thus the Tutorial D language) is easy to get to grips with and far from rocket science to program.

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. Okay, it's long-winded, but it generally does the job and with the proprietary extensions that the likes of Microsoft, Oracle and the like have plonked on top of what ANSI says should be there.

But as an exercise in better understanding how databases work – and, more to the point, how databases perhaps ought to work, and might just work one day – Darwen and Date's work is well worth a read, and Voorhis' D4 implementation is well worth looking at.