In what areas are (recently build in the internet era) NoSQL Databases beneficial over (barely-)Relational traditional RDBMS Databases (build decades ago)?
----
Scalability, the easy to mutate schemas and all that are artifacts of our times.
MySql, Sql Server, etc are barely relational databases, coupled with a almost-decent way to interface them (sql).
For example, in them you can't store a relation inside a field. Schema manipulation is hard. A lot of potential programming power is not possible, without convoluted recent additions the Sql language, or hacking together strings.
And most of them have been made for workloads and scenarios that are at odds to what internet-scale companies need.
Unfortunately the solutions was do "Nosql":
"Any sufficiently complicated database management system contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a good RDBMS."
---
Check the relational model. Is far simpler than people give credit, even without get too crazy like some purist want.
In fact, I don't see any reason why the relational model can't
be used as flexible how json is applied in the backend.
---
Despite all the above and more, a traditional RDBMS is solid enough that most people not need to get crazy and move to (full) NoSql. However, could be good to use them in specific cases (like caches, search engines, etc).
But I have experience people using NoSql stores and trying to do the kind of work a RDBMS have solved easier and faster.
The real question is:
In what areas are (recently build in the internet era) NoSQL Databases beneficial over (barely-)Relational traditional RDBMS Databases (build decades ago)?
----
Scalability, the easy to mutate schemas and all that are artifacts of our times.
MySql, Sql Server, etc are barely relational databases, coupled with a almost-decent way to interface them (sql).
For example, in them you can't store a relation inside a field. Schema manipulation is hard. A lot of potential programming power is not possible, without convoluted recent additions the Sql language, or hacking together strings.
And most of them have been made for workloads and scenarios that are at odds to what internet-scale companies need.
Unfortunately the solutions was do "Nosql":
"Any sufficiently complicated database management system contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a good RDBMS."
---
Check the relational model. Is far simpler than people give credit, even without get too crazy like some purist want.
In fact, I don't see any reason why the relational model can't be used as flexible how json is applied in the backend.
---
Despite all the above and more, a traditional RDBMS is solid enough that most people not need to get crazy and move to (full) NoSql. However, could be good to use them in specific cases (like caches, search engines, etc).
But I have experience people using NoSql stores and trying to do the kind of work a RDBMS have solved easier and faster.