nosql-vs-rdbms-let-the-flames-begin.html. From my perspective, this debate isn't really a debate and I've written about similar things before.
If you stop for a moment and think, it seems obvious that giving up a relational model and giving up ACID compliance reduces overhead. It should also be obvious that you are giving up things that many people for many years have thought are really important.
To a person selecting an underlying database implementation, part of your decision making process needs to take these things into account. Here's a quick list of things to consider:
- How important is speed? (how long can we wait for one operation to finish)
- How important is scaleability? (how many operations must we be able to do at one time)
- How much money can I spend? (Can I spend a $200,000 on a honking server?)
- Who is going to support this system? (A bunch of developers, a bunch of dbas, or both?)
- How big are my transactions? (Am I updating 100 unrelated things in one transaction?)
- How important are transactions? (if update "A" fails, do I really have to rollback update "B")
- Do I need to replicate my data? (does hong kong need the SAME data as the US)
- Do I need to shard my data? (should hong kong orders stay in hong kong and never make it back to the US?)
- How much data are we talking about? (managing a 1gb database is quite a bit different than 1Tb)
- How often does the data change? (is this a transactional system, append-only, or read-only)
- How much of the data changes? (the weather changes every day, the text of a book written 100 years ago doesn't change very often)
While this list isn't comprehensive, it illustrates the sorts of things people should be thinking about BEFORE even trying to pick which sort of solution is appropriate. What I find is that many people try to make significant architectural and highly technical decisions without having thought about what they're really trying to do and what is really important for that particular solution.