I have a mostly-written second draft on this: if your data doesn't need to be relational, by YAGNI you should use nosql, right? I want to explore the idea of "requirement perturbations": small feature requests that clients ask for which could throw your whole design out of whack https://twitter.com/coreyhaines/status/1188975315663622144
Like how it's easy to progress a game by just updating the state each time, but if the client then asks for an undo feature, then that "perturbation" forces you to redesign your program around keeping a state history, or calculate state from a list of events. Stuff like that.
If we could figure out some common perturbations, then we can determine if a given system is fragile, in that the customer is very likely to ask for a feature that forces us to start over.
Fex "show entries in group" might lead to a request for "show all groups containing entry"
Fex "show entries in group" might lead to a request for "show all groups containing entry"
In that case it's way easier to incorporate that request if you have a relational model than if you're schemaless
Then you might have something like "show all categories these two entries share" which makes things worse
So SQL would be more stable under common perturbations
Then you might have something like "show all categories these two entries share" which makes things worse
So SQL would be more stable under common perturbations
On the whole we accept that requirements often change, but we don't really study it as a phenomena, just treat it like an act of god or something
I still like the idea but I can't quite make the essay as watertight as I'd like so it's mouldering in draft hell
I still like the idea but I can't quite make the essay as watertight as I'd like so it's mouldering in draft hell