I am asking this question as I am developing a data access solution that will change the data access development into SQL development, but requires the above tools. Thanks.
Yes. Many of them. A lot of them are retiring now, but I know plenty of younger DBAs coming in without any other programming experience and in many cases, no desire to learn.
SQL is one of the most widely used languages, and it's going to depend on what segment you are targeting.
Can you abstract this to a DB host?
Why are these extra tools a requirement to use your solution? It's better to meet your users where they are, let them use the tools they already know and use daily
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.
Many business analysts use SQL, have for a long time. They are probably not your target audience. With the problem being code specific, you'd likely want to start there, with devs. Most SQL users are not going to understand these things
This sounds similar to the goals of my hof tool (https://github.com/hofstadter-io/hof), lift type definitions out of code so they can be defined in one place, then generate the code for all the places. Is that sounding like what you are after?
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/).
I would go the VS Code path were I to do it over, could still make it a plugin I suppose...
I would say keep iterating on the docs. It's unclear to me what problem this solves and what it looks like in practice. It's probably too technical out of the gate (above the fold). One of the best things you can do is look at successful projects to see what they are doing. Take things you like from them, test it with potential users. It's very hard to step back from your own project to simplify and reduce the explanations.
