Comment by j45

Given how many accounting systems don’t use relational tables but use a relational db (like sap b1) and do joins manually, it would be a big step forward.

I have seen more than a few accountants dream about learning sql instead of their excel tai-chi.

I taught some to see sql as a sentence that was an instruction to join the columns they wanted.

Since everything is actually related tables.. it would be possible to just hand them something like metabase to start for all reporting since it can traverse and build up queues no problem.

The parent-child relationship I ran into as well as being an issue. It gets increasingly out of control and more complex that I wonder after a certain level of complexity whether sql is the best or sole way to go. I don’t know if this can be avoided at the cost of the user needing to know how to to do complex queries. Maybe there’s a way to simplify it with invoking stored procs somehow.

From this parent-child complexity side of things I explored graph databases for this and it seems to off some potential advantages, particularly for some complex use cases and queries. Keeping it postgres specific, PG can be extended with Hasura and then graphql is be available on the underlying schema. It really is something.

Beyond this, I’m spending more time with a knowledge graph databases outright.

If you haven’t had a chance, I highly suggest checking out TypeDB and a few demo videos. Chances are you will get to see some things you won’t be able to unsee and how it can help the Postgres design.

One of my use cases (non accounting) is sufficiently complex on the parent-child front that I have a basic interface between Postgres and TypeDB working to allow much easier querying and reporting via TypeQL.