No, they're how you, as what sounds like a predominantly object-oriented programmer, use data. And that's fine, but don't pretend it's universal. A programmer approaching a problem from a functional perspective may well exploit the relational nature of an RDBMS to work smartly within the paradigm. (I've seen it done, and done very well and easily, in a way that's approachable even for relatively novice functional programmers.) Even if using an object-oriented style of programming, with the feature set of something like PostgreSQL--or SQL Server, if that's your bag--and the ability to very easily provide assurances around data integrity and correctness using the built-in tools, you have a very powerful and easy-to-use set of tools for building a rugged, correct data model. For product developers that do not find a cavalier approach to users' data to be acceptable, this can be a wise choice. Being fast and wrong is not always the right answer (and I personally consider it to usually be the wrong one).
But it's even better to be fast and right, and that can quite obviously be done, in many cases, with a relational data store. And this may mean understanding how to write code in a style that doesn't necessarily use the Active Record pattern or a similar ORM. That's true. But that does not imply an inherent product development benefit to using such a tool (for their partisans), nor does the common reliance on these tools and its well-documented failures imply that the various NoSQL technologies are better at building a product.
User1 firstname1 lastname1 role1 rolename1
User1 firstname1 lastname1 role2 rolename2
User1 firstname1 lastname1 role3 rolename3
This is purely a result of how the database works. That data is never presented to the user in that way. It has to be converted into a new form.
NoSQL databases are much nicer to work with for typical web applications (yeah, even the ones with relational data). They are much closer to how we actually use data as a programmer. Most startups using a SQL database will be using an ORM, which is a massive piece of software designed to make SQL databases more compatible with how we actually work. Even then, they still don't have the flexibility you get from using a nosql solution.
As for this article, it is hard to get past the fact that he thinks the only reason to use nosql is for scalability. He also states that mysql was fine, yet fails to understand that the massive startups using mysql didn't use it at all like a relational database.