3 ms·

Honestly I've never found a programming language where SQL didn't have some tedious tasks. There are always lots of little edge cases and error handling etc th

Honestly I've never found a programming language where SQL didn't have some tedious tasks. There are always lots of little edge cases and error handling etc that never seems to be fully covered by the libraries. That said, for a CRUD type app, I usually default to node.js unless the requirements would exclude it for some reason, then I'd move to Go, but generally I avoid writing new Java anymore, not that I think Java is bad or evil, I just prefer other languages. For node we use the pg-format package to format most of our queries and then the standard pg package to execute queries. It is honestly one of the easier and cleaner ways methods I've used. I am not a big fan of ORM's and find a lot of them add way to much complexity for too little benefit, so I am a big fan of either stored procedures/functions or straight (but safe) query building. I have written code in node.js, Go, C & C++, Java and Python to manipulate data in different sql databases and they all have some form of tedious tasks in relation to the SQL integration.

jennoo 7y ago
I also try to avoid ORM's but ditching them makes mapping to struct/objects cumbersome. How you deal with mapping joins in Go and node.js?
- davismwfl 7y ago
  I find having results in object form for CRUD API's most of the time is unnecessary, and this is a lot of what happens and people use ORM's for. When I do need the data in object form I use what is probably an unpopular method for a lot of people, that is I build a serialize/deserialize solution (or use one already built). It isn't hard in either node.js or Go. It can add some fragility into the codebase, however, depending how it is implemented. Frankly though, I like this because essentially this is what an ORM would do too, just an ORM would be trying to build the query, guess on keys, indexes etc and then still serialize and deserialize my data, which again may not be ideal because of generic choices it has to make. Also, a fairly common pattern for CRUD APIs is I do not need to map the returned data into an object ever, I simply need a json object to return. And at least when using postgres I can use jsonb_agg and to_jsonb to help make life really easy. MySQL has similar json functions. When doing updates the submitted json data is used to build the query so there is no need to really have things in native object form. Hopefully that all makes sense.

jennoo 7y ago

I also try to avoid ORM's but ditching them makes mapping to struct/objects cumbersome. How you deal with mapping joins in Go and node.js?

davismwfl 7y ago
I find having results in object form for CRUD API's most of the time is unnecessary, and this is a lot of what happens and people use ORM's for. When I do need the data in object form I use what is probably an unpopular method for a lot of people, that is I build a serialize/deserialize solution (or use one already built). It isn't hard in either node.js or Go. It can add some fragility into the codebase, however, depending how it is implemented. Frankly though, I like this because essentially this is what an ORM would do too, just an ORM would be trying to build the query, guess on keys, indexes etc and then still serialize and deserialize my data, which again may not be ideal because of generic choices it has to make. Also, a fairly common pattern for CRUD APIs is I do not need to map the returned data into an object ever, I simply need a json object to return. And at least when using postgres I can use jsonb_agg and to_jsonb to help make life really easy. MySQL has similar json functions. When doing updates the submitted json data is used to build the query so there is no need to really have things in native object form. Hopefully that all makes sense.