Many special-purpose databases don't need, or use, either the relational model or a declarative language such as SQL. An interesting group of these are sometimes called BASE systems (Basically Available, Soft State, Eventually consistent) and they work well with simple data models holding vast volumes of data. Google's BigTable, Dojo's Persevere, Amazon's Dynamo, Facebook's Cassandra, and a host of others.

The 'NoSQL movement' is the latest group for developers who are working with or building non-relational BASE distributed databases, and particularly the open-source varieties. This would be no more than an interesting aside, to remind us that SQL-based relational databases are general-purpose tools and there will always be, and always has been, a thriving industry of special purpose database solutions. However, journalists commenting on the startup of the 'NoSQL Movement' cannot resist a tease. "Like the Patriots, who rebelled against Britain's heavy taxes, NoSQLers came to share how they had overthrown the tyranny of slow, expensive relational databases in favor of more efficient and cheaper ways of managing data." burbles Eric Lai over at Computerworld.

Sometimes, when the red mist of radicalism descends, it is possible to lose sight of the fact that RDBMSs such as SQL Server fit closely with the requirements of complex commercial business systems. Your system may, in fact be trivial, but hold huge quantities of data. Everyone thinks they are working with highly complex data models. It is part of our vanity as developers. It leads to absurd generalisations such as "Relational databases give you too much. They force you to twist your object data to fit a RDBMS". The problem often boils down to a developer with a filofax-sized database having to use a grown-up RDBMS. There will always be tears in such circumstances.

From a distance, an RDBMS such as SQL Server may seem like overkill, especially for a simple social-networking website. As soon as you get to the details, such as concurrency, consistency, scalability, and ease of refactoring then the idea of an open-source EAV database alternative can start to get less attractive. Even the idea of ditching the use of SQL soon hits problems. A Declarative language may seem odd to those who are only familiar with proccedural coding, but it is a fine way to allow parallel processing. I must admit that occasionally, when faced with designing an IT project that deals with data that strays from the conventional relational model, I've flirted with the use of special-purpose databases, but there always comes a time when the niggles of the details of implementation start rising exponentially, and one wakes from the dream to return to the SQL-based Relational database systems such as SQL Server.