I don't really buy that. I have built applications using BDB on the back-end. It works really well for some things. It just has other shortcomings development-wise that usually makes up for the benefits and then some.
The thing is that object-oriented and relational design are fundamentally different. It is very rare to find people who are very good (or even equally good) at both. They are entirely different design disciplines aimed at very different problems. What non-relational db's do is they free the developer up from this second, very different discipine using tools that usually perform very well for standard OO operations.
That's a powerful thing.
Of course it's also powerful to have a math engine which can take your stored data, digest it, and spit out a report based on criteria you hadn't thought of until 30 seconds ago. And iterating through a collection of objects? Not a good way to do that.
> That's a powerful thing.
I have been working with people who know relational databases and OO. And I have been working with people who could only do one of these things.
I know with which group I prefer to work.
If a technology is used as a "don't worry: low barrier to entry" to keep the challenged on board, it will become a great measure for lack of competence if you know it.
Seriously, until now nosql advocates would use specific technical merits of the different options we have now, but "developers don't grok rdbms's": its not an argument. According to some, developers also don't grok fizzbuzz.
If you can't wrap your mind around set theory you should also not iterate through a collection of objects.
True enough, but there is a reason why OpenLDAP's performance is atrocious when run with an SQL back-end.
My own viewpoint is that there are cases where the relational model really offers very little of benefit and a lot in terms of cost, but that these are far more narrower than the NoSQL guys suggest. I see NoSQL at its best being a niche tool.
Remember with NoSQL, there's one answer when your customer say "can I tweak this report?" NoSQL? Answer is "No!" of course!
The thing is that object-oriented and relational design are fundamentally different. It is very rare to find people who are very good (or even equally good) at both. They are entirely different design disciplines aimed at very different problems. What non-relational db's do is they free the developer up from this second, very different discipine using tools that usually perform very well for standard OO operations.
That's a powerful thing.
Of course it's also powerful to have a math engine which can take your stored data, digest it, and spit out a report based on criteria you hadn't thought of until 30 seconds ago. And iterating through a collection of objects? Not a good way to do that.