> Later, if you realize that each movie can have multiple directors
This still require change across the codebase, where the db migration is fairly, the most simply step.
But:
Is similar to "static VS dynamic" where the change in rdbms come BEFORE the new data and in most nosql AFTER.
If somehow the data come in a "progressive do changes pls" then is clear the way most db schemas are, is harder with BEFORE.
So, yeah, exist places that a specialized store make more sense. But just say "is harder" invite this critique, and worse, in the minds of inexperience developers (that are the ones that deploy blind) could lead to "get out of a rdbms, are old and bad!", when in fact is much better, most of time.
ALSO:
> Restricting direct access to rigid RDBMs and making data modeling easier via graphs is why....
The relational model could handle that. BUT, the implementation inside rdbms is just a subset of the full potential. One example: You can't embed tables in tables.
And relational/sql engine have weak support for hierarchies and graph, despite the fact you see sql on top of other non-relational engines.
I'm building a relational lang in the spare time, and without the constrain of fit the(traditional) rdbms is clear the db guys need to up their game!
This still require change across the codebase, where the db migration is fairly, the most simply step.
But:
Is similar to "static VS dynamic" where the change in rdbms come BEFORE the new data and in most nosql AFTER.
If somehow the data come in a "progressive do changes pls" then is clear the way most db schemas are, is harder with BEFORE.
So, yeah, exist places that a specialized store make more sense. But just say "is harder" invite this critique, and worse, in the minds of inexperience developers (that are the ones that deploy blind) could lead to "get out of a rdbms, are old and bad!", when in fact is much better, most of time.
ALSO:
> Restricting direct access to rigid RDBMs and making data modeling easier via graphs is why....
The relational model could handle that. BUT, the implementation inside rdbms is just a subset of the full potential. One example: You can't embed tables in tables.
And relational/sql engine have weak support for hierarchies and graph, despite the fact you see sql on top of other non-relational engines.
I'm building a relational lang in the spare time, and without the constrain of fit the(traditional) rdbms is clear the db guys need to up their game!