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.