kw123

The best SQL extension I could find for MySQL and PostgreSQL is Database Client.

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.

Thanks a lot. I fixed it.

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:

[ { "id": 1, "arr1": [ { "id1": 1 } ], "arr2": [{ "id2": 1, "arr3": [{ "id3": 1, "val": "abc" }] }] } ]

the single SELECT statement for the query is like:

select 10 as id, 1 as id1, 2 as id2, 3 as id3, 'X' as val union all select 20, 2, 4, 6, 'Y'

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.

Hi HN!

There were an old thread on HN years ago asking people what they prefer, raw SQL or ORM?

https://news.ycombinator.com/item?id=16809620

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:

https://www.backlogic.net/

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.

https://marketplace.visualstudio.com/items?itemName=BackLogi...

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.

Thanks for your comments. This is actually a externalized layer between RDS and application. It hosts the persistence logic normally implemented by ORM. However, this platform attempts to provide a simpler method for creating the logic. For example, to create a query service, you would just specify the input and output for the service with JSON and then a SELECT statement for the query. The other two services you may create include a SQL command service and a aggregate CRUD service, all with help of a GUI Service Builder. With your comments, I see the need to carefully phrease my product to avoid confusing. Thanks.

You would need somebody who believes in your idea or shares your vision. I have been on the other side, but was just not as convinced and hard to get motivated. So I feel I know why a potential helper may not actually help, even offered with shares.