NoSQL movement - justification for SQL RDBMS

In past year I've made numerous projects wit开发者_开发问答h NoSQL json based databases - the rich kinds (not the key/value stores) - such as CouchDB, MongoDB, RavenDB. I talk to fellow programmers often about my adoption, I notice though I'm always quick to add "of course SQL RDBMS system still have a place, its always whats best for particular project/task" - as a little disclaimer so not be seen as kool aid drinker, however its pretty shallow statement. Outside of legacy projects that already have an investment in RDBMS, or corporate mandates insisting on Oracle, I struggling to think of any future green field project I'd opt for a SQL database. Its CouchDB all the way for me as far as I can see with rich map/reduce, changes feed, replication support, RESTFUL api (sorry thats starting to sound like a plug)

I'd like to hear those that do "get" (beyond screencasts) NoSQL Json M/R databases such as CouchDb, what type of projects do you think you'll use MS-SQL, Oracle, Postgresql etc.. in the future ?

Thanks

One of the biggest strengths of SQL is that there is a standard way of modelling just about anything - for any given project it may not provide an optimal solution, but it does provide a reasonable one. This means that in a corporate environment you can decide that everything will be stored in Oracle to get the maintenance benefits of having a single system without the risk that it will be completely inappropriate for future projects.

This ability to handle different requirements without needing a lot of planning is also relevant at the start of projects where the design doesn't get signed off until six months into development - again, something that applies mostly in corporate development.

Using NoSQL properly generally requires better developers than you need for SQL development. One of the many SQL code samples available can be edited into a working system by someone who barely knows what they are doing. NoSQL does things like eliminating integrity checks for performance - a good developer produces well tested code that doesn't insert invalid records or understands why a few invalid records don't matter for a particular app. A bad developer thinks anything without error messages is good code. The average developer at a successful web startup can probably handle it. The average developer maintaining internal corporate apps probably can't.

On my own projects where I have complete control of the platform choice and know both the requirements and who will do the development, NoSQL is as good a complete solution as you suggest. Nothing really matters except the technical advantages - easier to code, easier to maintain, better performance, horizontal scaling.

In the corporate environment it's the other realities that dominate - incompetent developers, unknown/changing requirements, long application life cycles, the need to minimize the number of systems - NoSQL wasn't designed for that problem set.

Off-hand, I'd simply say that if the data is inherently relational, an RDBMS is the optimal choice. For instance, an order management system is a good fit for an RDBMS. If the data is not inherently relational (like Google's search index, for example), than NoSQL is a better choice. They both have their place.

My latest application is massively hierarchical/relational with objects containing sub-objects containing sub-objects, all related by natural keys. It's a perfect fit for an RDBMS, and would have been much trickier in a NoSQL DB.