Hacker News Reader

Comment by simonbarker87 | Hacker News Reader

I feel like one of the few JS devs who is happy to just write SQL. Inline or as a stored procedure I just don’t see how learning an ORM and all it’s issues and bugs is harder than learning SQL.

View on HN

Yay another non sql fearing js dev. I feel as though we're rare

Reporting for duty. I never feared SQL after https://www.sqlteaching.com/

Granted, there's much more to learn than that, but so is the case with ORMs. I've had more issues writing good ORM queries than SQL queries.

Great (and fun!) resource. https://pgexercises.com/ for more in depth on aggregates + recursion.

I thought we were rare while reading through the comments on this article about ORMs, but then I realised that the SQL community is huge and anyone fine with SQL would more likely be posting over there.

https://blog.logrocket.com/why-you-should-avoid-orms-with-ex...

At the risk of sounding arrogant, why do people fear SQL? If you can program in any modern language, you can pick up SQL.

There is no good JS ORM, so it's for the best.

Best practice, in the case of JS, is to use MongoDB, which has a native JS query API, and then use microservice patterns to provide joins, two-phase commit, and (eventual) consistency.

Why would your database choice have anything to do with your language choice?

Because your programmers don't know SQL and don't want to. In an ideal world of perfectly spherical programmers, choosing JavaScript would be completely orthogonal to database choice, but in reality one common symptom of JavaScriptitis is considering SQL an old relic that's too much of a pain in the ass to learn. Thankfully, MongoDB's query language is JavaScript and its result sets are JSON objects.

To be fair, this sort of feeling toward SQL is not found uniquely among JavaScript programmers; one major reason why we have ORM hell is because a previous generation of programmers did not want to leave the warm cocoon of treating data as objects in Java.

Assuming you're not being facetious (which I'm not sure of)...

You have described why people make such decisions, but you have not yet made an argument for whether it's wise or not. Can you imagine why it would be an unwise decision?

Even if you have engineers who stubbornly refuse to learn SQL (a problem with your engineering management if there ever was one), there's always options like Hasura [1].

[1] https://hasura.io/

I know youre joking but why do I feel so hurt?

There's no good ORM.

Entity Framework (in .NET) is good. Looks like this package takes a lot of the feel of Entity Framework transferred over to node.js

Oh interesting! I'll have to check it out!

EF is slow, IMX. But I think it mainly has to do with the fact that it's an ORM, and since the application un-marshals to objects and marshals back to the data store more or less one object at a time, you lose set-based operations. If you're interacting with a lot of discrete, unrelated objects, that gets really inefficient. You can easily end up with the dreaded "row by agonizing row" pattern:

  UPDATE Student SET Grade = '04' WHERE StudentId = '12345'
  UPDATE Student SET Grade = '04' WHERE StudentId = '12346'
  UPDATE Student SET Grade = '04' WHERE StudentId = '12347'
  UPDATE Student SET Grade = '04' WHERE StudentId = '12348'
  .
  .
  .
  .
  UPDATE Student SET Grade = '04' WHERE StudentId = '12349'

Instead of:

  UPDATE Student SET Grade = '04' WHERE StudentId IN ('12345','12346','12347','12348', ...., '12349')

Oh it can be slow, not all of the entity framework adaptors support bulk operations. I ended up extending it a bit on my object model to include bulk operations which do pretty much what you have there (I stuck to delete and insert though). However, I have used a pile of ORM products since the early C++ / smalltalk days back in the 1990s and it's easily the best ORM I've ever used.

ActiveRrcord is pretty good. So is Sequel.

prisma is amazing, takes 5 minutes to setup, and lets you make just about any query with minimal typing, unlike making raw sql.

You should spend more time here. I'm fairly certain that, if HN is representative, nobody likes ORMs. (Also: advertisement works on nobody)

Personally, I love solving fancy puzzles with SQL but honestly prefer Rails' ActiveRecord ORM because it drastically cuts down on typing.

I don't really like ORM's (or even java) but if I'd have to write code to model a typical user/product/subscription system I'd rather use hibernate with some annotations than dealing with all the add/update sql and projections between domains.

That's too simple and efficient and too easy to debug. Need more layers.

Developer here frim the Ruby world (although I wrote extensively Elixir and now Go). I can't even begin to describe the amount of damage ORMs repeatedly do (ActiveRecord being particularly magical). Our team writes sql rather than ORM and we have way less problems, not to mention we get better at SQL, so our team is also the one you refer to when you need to optimize things.

We do use query builders when we need to, usually the scenario is: a form with incremental filtering (multiple conditions), but not a full fledged ORM.

Opt for the stored procedure whenever you can. Your database will be able to yield much better performance - even if you have average SQL skills. If you have a SQL query giving you performance fits then you can bring in someone with greater SQL expertise to optimize it for you and your code isn't impacted.

Reply on news.ycombinator.com