There are a few reasons why doing things like this in the RDBMS is a good thing for many use cases.
First, there is a ton of already built tooling for dealing with an RDBMS. This alone is why I think every project should default to using an RDBMS and only move if a good case can be made.
Second, like it or not, sql is the defacto language for querying the data. After 20+ years of writing software, I've used many languages, but sql (of course it has evolved) has been a constant across RDBMS. I've seen many service layers and front ends change over the years, all while sitting on the same RDBMS. Given the speed at which tech moves, it's pretty amazing when you think about it.
Finally, for things like graphs or json, it's often the case that I only need handle it in addition to my existing relational datastore. In some cases it might make sense to stand up an entire system for the use case (like a solr server for document searching), but many times I just need to store a bit of json or I have one or two graphs that need to be represented. In these cases, standing up an entire separate system adds unneeded complexity.
> I've seen many service layers and front ends change over the years, all while sitting on the same RDBMS
This.
And the youngsters never believe me, when I tell them that the application that they are writing is not the only one and will not be the last one to access the database.
My standard line for decades has been that the database is more important from the program. You can reconstruct how the program works from the database; you can’t reconstruct the database from how the program works.
A business might be interrupted if their programs accessing the database break. A business will _die_ if their database is lost.
I'm currently staring at a PostgreSQL database created by a Django app with a lot of inheritance between models.
My favorite /s is the table with a single column containing the id of the record itself.
It's basically impossible to start from the database and understand what's going on. It will be a huge pain to interface to this database from something else.
On the other side, I'm maintaining another Django app for the same customer, with saner tables (no inheritance) and that's on par with other ORMs.
Never use inheritance at all?
I was thinking you could reconstruct part of the app stack by observing and clustering the requests and transactions. But then some people think join is the devil and you'd be back to square one. In a perfect world every app would have only views over what they need and prepared requests. But then CI/CD and all kind of tests can become very painful...
I don’t make friends as easily as hating on any technology but I do make friends easily on kindness. Hi! I learned a lot great and not great working with DRF. Kind of took it and ran with it on TypeScript and Node. Working on a much better HTTP interface for that platform.
Reminds me of the Fred Brooks quote, "Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious."
Diving more into postgres recently, I‘m kind of surprised there is not the kind of tooling I know from (frontend) development. I would have expected there to be a number of tools for: version control, CI/CD, (integration) testing, performance monitoring, safe migration, developing stored procedures (in vscode, with hot reload), data shuffling (snaphshots, rollbacks...). Both open source and startups, SaaS services with online dashboards etc.
There are some ok options in these categories but nothing like the explosion of open source tooling out of bigcos and devtools/SaaS startups you see elsewhere.
There‘s... aurora, prisma, some pg extensions to get performance info?
Absolutely! I evaluated a bunch of migration management tools recently and was very disappointed. I needed something to develop and version stored procedures and just didn't find much. Ended up using graphile-migrate which has been great but also tightly bound to other parts of my stack. Would have expected more options from a 30+ year old technology.
First, there is a ton of already built tooling for dealing with an RDBMS. This alone is why I think every project should default to using an RDBMS and only move if a good case can be made.
Second, like it or not, sql is the defacto language for querying the data. After 20+ years of writing software, I've used many languages, but sql (of course it has evolved) has been a constant across RDBMS. I've seen many service layers and front ends change over the years, all while sitting on the same RDBMS. Given the speed at which tech moves, it's pretty amazing when you think about it.
Finally, for things like graphs or json, it's often the case that I only need handle it in addition to my existing relational datastore. In some cases it might make sense to stand up an entire system for the use case (like a solr server for document searching), but many times I just need to store a bit of json or I have one or two graphs that need to be represented. In these cases, standing up an entire separate system adds unneeded complexity.