If you have ever programmed for SharePoint, you probably had a look at the content database, just out of curiosity. And if you did so, you probably closed it and never looked at it again, because you can’t stand the outstanding abuse of SQL as a data store:

Yes, the columns are named “nvarchar1”, “ntext1” and so on. If you ever wondered why SharePoint has some strange limits on the number of variables on a list, now you know why. There are just so many columns of the respective primitive type in the user data table.

SharePoint tries to map non-relational data to SQL. On the one hand, it supports multiple Content Types per list, so each item can have a different set of attributes. On the other hand, it does not expose transactions, joins, or any other feature SQL developers use on a daily basis. It looks like they just had to find some kind of data storage which is accessible over the network and can be shared by multiple instances of SharePoint. In this regard, SQL Server seems like a reasonable choice, at least when your only alternative in the Microsoft product stack is SMB/CIFS.

Nowadays it looks to me as a great opportunity to use a document database as backend, such as MongoDB, RavenDB or CouchDB. If SharePoint List Items would correspond to documents, there was no need for mapping attributes to enumerated columns, they could be stored as is. SharePoint exposes nothing which could not be done on any of these NoSQL databases. I know that it is unreasonable to expect Microsoft to support a NoSQL backend in an upcoming version of SharePoint. But I would like to spread the word to show SharePoint developers that there is a sane world out there. And if they are ever in the position to design a system, they should evaluate all possible backends to find one which matched the concepts of the system, not just one which can be forced to do the job.