THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

Davide Mauri

A place for my thoughts and experiences the Microsoft Data Platform

Does NoSQL people really want to drop the relational model?

In these last days I’ve talked a lot with developers to understand why the “NoSQL” idea fascinates them so much. Or, put in other words, why they think that leaving RDBMS behind will help them.

Well, rephrasing again, I can formulate the question in a more direct form: “What you don’t like of RDBMS, that brings you to ask such huge change?”

I’d like to share with you what I discovered, even if the number of developer to whom I talked to is small and thus – maybe – not representative of the whole, but nevertheless I think is significant.

First important thing that immediately shows up, is that there a lot of confusion  between the Relational Model – the mathematical fundaments of RDBMS – and the physical implementation of it, which is the RDBMS itself.

I’m sure this is nothing new, but it’s an important point to keep in mind. This is the key to understand the NoSQL idea, and to give answer to it.

Developers complain that RDBMS does not scale. While, for my experience, this is not totally true, I can pretend to agree, but even in this case, the problem is in the implementation not in the model. Is not that leaving the relational model behind will make databases more scalable.

Other complains regard the fact that SQL is too verbose and quite frustrating sometimes because ask you to write too much “ugly” code. I agree with that. Writing queries to join many table on many columns is just boring. But again I don’t really see how dropping the relational model could help on this side.

One last big complain is that if a developer has an object – an instantiated class – and he only needs to persist it, he can’t. He have to map object attributes to tables and columns, which is, again, time consuming and boring. And in addition this doesn’t offer optimal performance since such mapping, of course, consumes resources. I agree also on this. But I know that in “Third Manifesto” this problem is totally solved, just making RDBMS aware of Object-Oriented principles. Now, if Microsoft can just integrated more and more SQL Server with .NET, the problem will be solved. I know that Oracle is way more integrated with Java, so we can ask for the same thing. But, hey, even here I don’t see how eradicating the relational model can help. On the contrary the proposed improvement of it can make our life easier and still safer (in terms of data quality).

So, at the end, my idea is that NoSQL doesn’t really mean “Throw relational databases away”, but more something like “Give me correct implementation of the relational model, make it capable to handle objects (in Object Oriented Principles way), make SQL less verbose and more integrated with .NET and give me something that I can scale automatically.”

As said before this is something I can understand and with which I can also agree. And some steps toward this objective has been already made, we just have to keep going in that way, even if it has lost it’s marketing power (I’m sure it’s easier to sell new features than improving the existing ones…)

Let’s have SQL Server that really implements the relational model so that I have do define my types so that I can be warned at runtime that I’m joining between Customers and Products but types are incompatible (even if they are just integers behind the scenes, just like classes are composed of base types!)

Let SQL Server be able to handle objects in an object-oriented way. Let me be able to use inheritance.

Make LINQ even more integrated with SQL Server. It would be nice if it could push queries directly to the SQL Engine, without having to convert it into SQL anymore.

Make T-SQL less verbose. Give me NATURAL JOIN, complete OVER support and make ASSERTIONS and DEFERRED TRANSACTIONS available. (If you agree with that, please make Microsoft aware of it, voting connect feedback here and here)

Huge scalability is on its way with Madison, so maybe here we’re half the way through.

The conclusion, at the end, is that we don’t need to kill the relational model. Instead we "simply" need to have its implementation made better and better. That’s my idea. Do you agree?

Published Friday, October 2, 2009 9:03 AM by Davide Mauri
Filed under: ,

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS



merrillaldrich said:

Yes on all counts! Well put.

October 2, 2009 11:57 AM

Jeff Moden said:

Heh... SQL is too verbose?  Has anyone ever looked at all the stuff folks go through to manipulate data in Java or C?  Now THAT's verbose! ;-)

October 2, 2009 2:04 PM

Scott Whigham said:

I always love these types of discussions - interesting post. I'm with you on the NATURAL JOIN and OVER but, when I read the part about "Let’s have SQL Server that [lets me] define my types", I perked up a bit for a few reasons. For one, I like your idea of "I can be warned at runtime [about incompatible types in my query]" but to get such a warning in today's SQL Server would not require allowing you to define "my" types, would it? IMO that would really be more of a tweak to the query engine or to the optimizer.

The other reason I thought to write in was to ask how your wish for user-defined types is different from the old user-defined data types (not the user-defined types in SQL 2005 but the older UDDTs that we've had forever)? You mentioned "even if they are just integers behind the scenes, just like classes are composed of base types" which is exactly what the older UDDTs are.

October 3, 2009 5:31 AM

Davide Mauri said:

@Scott: the idea of begin able to defin own Types is not mine at all, it comes directly from C.J.Date. You can find a complete discussion of it in the "Introduction to database system, 8th edition", Chapter 5.

Also you can read about TYPES in the new "SQL and Relational Theory" book (always from Date):

The old UDTs have a big problem. Even if the tables that uses them are completely empty, you cannot change their definition. To change the definition you have to change all tables so that no references exists to them. A little painful, isn't it?

Beside this technical problem, old UDTs doesn't allow us to define how they can deal other other types: you cannot define CASTing rules nor, opertor usage and so on. All things you can do with .NET types (classes).

All this feature will really help developers and professional db users to write query that as less errors and verifiable at "compile" time.

This brings efficienty, ease of use and lower maitenance costs since the RDBMS will help you to avoid errors.

October 4, 2009 7:16 AM

David Portas said:

October 4, 2009 1:38 PM

Davide Mauri said:

@David: you have a great blog, really interesting!

October 5, 2009 4:45 PM

Jason Strate said:

Great points and a great read.

October 6, 2009 2:15 AM

Davide Mauri said:

Beside my BI workshop on Friday , this year at PASS Summit I’ll also contribute by participating at the

October 13, 2010 5:30 PM

abx said:


May 31, 2018 11:08 PM

chenqiuying said:


October 10, 2018 6:40 PM

qqq said:


March 27, 2019 12:44 AM

Leave a Comment


About Davide Mauri

Director of Software Development & Cloud Infrastructure @ Sensoria, an innovative smart garments and wearable company. After more than 15 year playing with the Microsoft Data Platform, with a specific focus on High Performance databases, Business Intelligence, Data Science and Data Architectures, he's now applying all his skills to IoT, defining architectures to crunch numbers, create nice user experiences and provide meaningful insights, all leveraging Microsoft Azure cloud. MVP on Data Platform since 2006 he has a very strong background development and love both the ER model and OO principles. He is also a fan of Agile Methodology and Automation, which he tries to apply everywhere he can, to make sure that "people think, machines do".

This Blog


Privacy Statement