You are right. Not business analyst. I am thinking development DBA type. I used to be one of them.
You tool looks interesting but mine is different. I offer a vscode tool for user to develop data access services(query, command and repository services) with SQL and JSON. Once the services are done, they are deployed to a runtime server (which is why docker-compose) to provide data access as service to the client application. I have a link here, in case that you care to take a look (https://www.backlogic.net/).
Data access layer is currently coded in applications, using Java for example, causing so called object-relational impedance mismatch problem. To solve this problem, I attempt to take SQLs out of Java and make data access layer pure SQL. Thus I will need JSON to specify the nested data structures of input and output objects. Since this come from the application side, the tools are more application aligned. SQL editor alone is not sufficient, although the work is mainly SQL development now. I am trying to figure out which group I should be targeting, the traditional application developers or the new SQL developers.
This is a concept different from ORM for solving the object-relational impedance mismatch problem. It:
a) Abstracts away the host language (Java etc.) from SQL, so that data access logic can be built with SQL only;
b) Abstracts away the hard object-relational transformation problem from developer, so that the developer has the flexibility to query objects of any shape he/she needs from PostgreSQL or MySQL. Here is the output from an example query service:
I have exactly the same feeling. Schema vs schemaless is like static typed vs dynamic language. The extreme is java vs JavaScript. With JavaScript, you have all freedom to construct objects with whatever properties, then you pay with hard-to-detect runtime errors. That is why people are going for TypeScript nowadays. I have learned this hard way, as I had hated Java so much sometime ago. For that I used quite bit Groovy, but later I had to refactor some with Java just for static typing, to avoid running time problems in critical area.
There were people suggesting "Raw SQL is always better" and people saying "Use an ORM. There's just no reason not to.", as you may expect. However, regardless of the choice you make, you code it in your application with the language you choose for the application, which I think is the root cause for the awkwardness of working with relational database.
Data access service is different. You compose it in its own database-centric environment, and deploy it as a backing service to your application for data access.
More importantly, data access service is standardized, declarative (with SQL and JSON only), aggregate-oriented, transaction-less, tool-driven and cloud-native,
aiming to bring a change to the way and the experience of working with relational database.
If you want to read a bit more about data access service, here is my site:
If you want to try it, here is the link for installing Service Builder, which is the tool for developing data access service, and is a VSCode extension.
Once you have it installed, open the Getting Started tutorial inside, start a try session with TryWithoutSignup button, and go through the steps of creating query, SQL and CRUD services.
At the moment, it is just a POC. Please take a look, try it and see how you like it or not like it. Your feedback is greatly appreciated either way.