5 ms·
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
by simonbarker87 5y ago
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.
- dyeje 5y agoThere is no good JS ORM, so it's for the best.
- bitwize 5y agoBest 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.
- yowlingcat 5y agoWhy would your database choice have anything to do with your language choice?
- bitwize 5y agoBecause 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.
- yowlingcat 5y agoAssuming 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/ https://hasura.io/
- thinkingkong 5y agoI know youre joking but why do I feel so hurt?
- henvic 5y agoThere's no good ORM.
- smackeyacky 5y agoEntity Framework (in .NET) is good. Looks like this package takes a lot of the feel of Entity Framework transferred over to node.js
- ckmar 5y agoOh interesting! I'll have to check it out!
- da_chicken 5y agoEF 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')
- smackeyacky 5y agoOh 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.
- rubyskills 5y agoActiveRrcord is pretty good. So is Sequel.
- zackify 5y agoprisma is amazing, takes 5 minutes to setup, and lets you make just about any query with minimal typing, unlike making raw sql.
- user123456780 5y agoYay another non sql fearing js dev. I feel as though we're rare
- mettamage 5y agoReporting for duty. I never feared SQL after https://www.sqlteaching.com/ 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.
- lawrencechen 5y agoGreat (and fun!) resource. https://pgexercises.com/ https://pgexercises.com/ for more in depth on aggregates + recursion.
- tsian2 5y agoI 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-examples-in-node-js-e0baab73fa5/ https://blog.logrocket.com/why-you-should-avoid-orms-with-ex...
- omegalulw 5y agoAt the risk of sounding arrogant, why do people fear SQL? If you can program in any modern language, you can pick up SQL.
- Scarbutt 5y agoThat's too simple and efficient and too easy to debug. Need more layers.
- IfOnlyYouKnew 5y agoYou 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.
- macromagnon 5y agoI 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.
- taylodl 5y agoOpt 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.
- Fire-Dragon-DoL 5y agoDeveloper 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.