If only two years ago somebody had dared to suggest that RDBMS was not the first choice and the future of data modeling, nobody would had believed him. However, there have been a lot of talk about non-relational (“NoSQL“) databases emerging (refer to 1, 2, 3, 4). Evidence for their success: Facebook (refer to 5), Twitter, Google, and Amazon heavily prefer NoSQL solutions.
Rob Conery recently wrote a bold and astonishing statement:
“… If you need a join, you’re doing it wrong – default to denormalization.”
“Default to denormalization”. Wow! So here we are now: The times of “do normalize, do normalize, just do it” are over! Normalization alway is a performance issue and for simple data models there is actually no need for maximizing integrity by normalizing. As far as I am concerned, the strongest pros for non-relational NoSQL dbs are
- performance and
There have been a lot of reports saying that migrating from relational to non-relational models have saved them a lot of time and money (refer to e.g. 6). I must agree: If you ever had to go through the hell of coping with the object-relational impendance mismatch and the Anemic Domain Model dilemma you would give anything to simplify your persistence layer. So many hours (months, years, decades) have been spend by developers dealing with these issues instead of focusing on the business logic.
However, when it comes to complex data models and where data integrity is more important than performance, I still believe in the power of RDBMS and their low-level consistance enforcement mechanisms. Since mixed solutions are encouraged too (refer to 6, 7), I guess an intelligent trade-off is the best solution: Using both data models alongside brings you the best from both worlds.
I am quite convinced that more and more project leaders will (have to) prefer NoSQL dbs wherever possible and carry on using RDBSM wisely wherever data integrity and complexity is an issue.
—- EDIT 08. Oct. 2010 —-
I already expected a quite controversial discussion, however, one important point needs to be added: Most NoSQL implementations are still in a very pre-mature state. Having played around with Java and Cassandra, I must say that integration turned out to be so hard (and buggy) that I just stopped wasting my time and returned to good old Hibernate/JPA/PostgreSQL.
In particular, I would like to mention Jonathans comment: “you wrote this post only a day after Foursquare published their ‘post-mortem’ after crashing with MongoDB and Digg seriously losing its users and firing their CTO for choosing NoSQL architecture.”
So with respect to my own experience and that of some other guys I should add: NoSQL is a great idea, but using it in production is imo a bad idea, because most nosql dbms are too pre-mature.
Nevertheless, I still like the idea and I am looking forward for the time when we will have some nosql dbms that prove to be stable enough for production.