I haven't actually used NoSQL in a project, so I can't speak to whether those disadvantages are worth the trade off or not in practice. What I can say is that it is a trade off to use a relational database.
The problem with relational databases is that constructing queries for anything but the simplest operations is incredibly counterintuitive, and easy to screw up in subtle ways. Then, the data you get out is usually nothing like the actual structure you need, so you have to process it and squish it into the shape you want. The common results I've seen of this are 1) programmers writing loops to execute simple queries that they can understand, and 2) programmers writing insanely inefficient or totally broken complex queries. And that's assuming that the database was designed correctly (or even sanely) in the first place.
And yes, you can use an ORM, but then it becomes even more questionable whether you're getting any sort of benefit over NoSQL.
The crux of the problem is that the standard-issue persistence mechanism for web development is something that superficially appears to be accessible via ordinary programming knowledge, but actually turns out to have been developed by a long lost Martian colony whose technological evolution followed a radically different path from our own. MySQL is not something you should jump into without having at least read a book on relational database design, and that's a step that many programmers clearly do not take.
Current NoSQL solutions clearly have their problems too, but from what I can tell, they don't seem to be insurmountable ones. And at least it's a step in a new direction, even if it's not quite the right one. Bad database design and use is a plague, and it's pretty clear by now that education alone isn't a practical solution.
The problem with relational databases is that constructing queries for anything but the simplest operations is incredibly counterintuitive, and easy to screw up in subtle ways. Then, the data you get out is usually nothing like the actual structure you need, so you have to process it and squish it into the shape you want. The common results I've seen of this are 1) programmers writing loops to execute simple queries that they can understand, and 2) programmers writing insanely inefficient or totally broken complex queries. And that's assuming that the database was designed correctly (or even sanely) in the first place.
And yes, you can use an ORM, but then it becomes even more questionable whether you're getting any sort of benefit over NoSQL.
The crux of the problem is that the standard-issue persistence mechanism for web development is something that superficially appears to be accessible via ordinary programming knowledge, but actually turns out to have been developed by a long lost Martian colony whose technological evolution followed a radically different path from our own. MySQL is not something you should jump into without having at least read a book on relational database design, and that's a step that many programmers clearly do not take.
Current NoSQL solutions clearly have their problems too, but from what I can tell, they don't seem to be insurmountable ones. And at least it's a step in a new direction, even if it's not quite the right one. Bad database design and use is a plague, and it's pretty clear by now that education alone isn't a practical solution.