> [...] in some instances you might work with vast quantities of data, or deal with transactional systems that just don’t easily fit the operational limitations of relational databases. And in those cases, you should consider moving some, or all, of your data into a non-relational database.
This is WRONG. With capital letters.
Confuse limitations of (the codebase/the enterprise/the specific RDBMS) with the MODEL:
> And in those cases, you should consider moving some, or all, of your data into a non-relational database.
Making data "non-relational" is not a cure for the above. Is more often than not, a regression (like some on this thread: Using JSON instead of regular tables!).
---
Now where we must focus instead is on make RDBMs more powerful (or more exactly: less constrained that cause less powers).
RDBMS are hurt more for the interfacing (SQL) and the design decisions of 40 years ago, but not because the "relational model" is the reason performance, scalability or anything like that suffer.
P.D: And also: Is incredible how many truly think the "relational model" is agains dynamic data. Even using SQL, that is a subset of it, is HIGHLY dynamic! What is a trouble, is that current RDBMS lack a easy way to embed relations in relation, forcing to detour to sub-optimal, ad-hoc, bug-ridden hacks.
> Making data "non-relational" is not a cure for the above.
ACID imposes a limitation on scalability, there is no way to escape that. If you want to claim that approximately nobody reaches that scale, that's true, and if you want to claim that you don't need to ditch your data schema, that's also true. But relations aren't worth much without global coherence, and global coherence requires ACID, and will only work up to some size (that fits almost everyone, but not literally everyone).
But is tangential to be relational. You can have relational data in a causal way. Now, i see that some think "relations" are PK/FKs and that only GLOBAL coherence is the only way to make relations to work.
If we can take a JSON and make it valid and correct only in this replica in this moment of time, relational data can too.
You replied to my reply, where I used addresses as an example. I totally agree with you in general, i.e. use RDBMS as much as possible, but when it's no longer possible - what would you do in the case of addresses?
The big problem with addresses and all that is the same whatever you use JSON or not (in the DB or in the app logic). I concede that using JSON in the DB and move the logic to the App is ok and in part because SQL is an incomplete language.
But that is orthogonal to move out completely to a nosql. That is going too far (in this case).
This is WRONG. With capital letters.
Confuse limitations of (the codebase/the enterprise/the specific RDBMS) with the MODEL:
> And in those cases, you should consider moving some, or all, of your data into a non-relational database.
Making data "non-relational" is not a cure for the above. Is more often than not, a regression (like some on this thread: Using JSON instead of regular tables!).
---
Now where we must focus instead is on make RDBMs more powerful (or more exactly: less constrained that cause less powers).
RDBMS are hurt more for the interfacing (SQL) and the design decisions of 40 years ago, but not because the "relational model" is the reason performance, scalability or anything like that suffer.
P.D: And also: Is incredible how many truly think the "relational model" is agains dynamic data. Even using SQL, that is a subset of it, is HIGHLY dynamic! What is a trouble, is that current RDBMS lack a easy way to embed relations in relation, forcing to detour to sub-optimal, ad-hoc, bug-ridden hacks.