HackerTrans
TopNewTrendsCommentsPastAskShowJobs

kw123

no profile record

Submissions

[untitled]

1 points·by kw123·2 jaar geleden·0 comments

Ask HN: Are SQL developers generally familiar with JSON, VSCode and Docker?

6 points·by kw123·2 jaar geleden·13 comments

Show HN: Build entire data access layer with SQL only

backlogic.net
3 points·by kw123·2 jaar geleden·3 comments

Ask HN: Is there still ORM hate these days?

6 points·by kw123·3 jaar geleden·8 comments

Show HN: Service Builder – Build data access layer with SQL and JSON only

marketplace.visualstudio.com
1 points·by kw123·3 jaar geleden·0 comments

comments

kw123
·2 jaar geleden·discuss
The best SQL extension I could find for MySQL and PostgreSQL is Database Client.
kw123
·2 jaar geleden·discuss
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/).
kw123
·2 jaar geleden·discuss
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.
kw123
·2 jaar geleden·discuss
Thanks a lot. I fixed it.
kw123
·2 jaar geleden·discuss
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'
kw123
·3 jaar geleden·discuss
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.