8 ms·

Couldn't agree with this more. The way I like to put it is "ORMs make the easy parts slightly easier, but they make the hard parts really hard". But I don't car

Couldn't agree with this more. The way I like to put it is "ORMs make the easy parts slightly easier, but they make the hard parts really hard". But I don't care that much about improving the easy parts, because they're already easy! Yet I can remember plenty of times when ORMs made my job a million times more difficult and all I was doing was fighting with the ORM itself (and usually at the worst time, e.g. when a query reached enough scale that it "fell over"). Query builders aren't exactly the same thing, but I love this article, https://gajus.medium.com/stop-using-knex-js-and-earn-30-bf410349856c https://gajus.medium.com/stop-using-knex-js-and-earn-30-bf41..., and it's made me a huge fan of Slonik and similar technologies. It does 90% of what I want a query builder or ORM to do (e.g. automatic binding of results to objects, strong type checking, etc.), but it lets me just write normal SQL. I also never understood this idea that SQL is some mystically difficult language. It has warts from being old, sure, but I'd rather learn SQL than whatever custom-flavor-of-ORM-query-language some ORM tool created.

ttfkam 3y ago
Agreed! First time I used the postgres Node library [0], I was sold! [0] https://github.com/porsager/postgres https://github.com/porsager/postgres
B-Con 3y ago
> but I'd rather learn SQL than whatever custom-flavor-of-ORM-query-language some ORM tool created This point is worth emphasizing! When you application carries non-trivial business logic, it will create non-trivial DB access patterns. The developer will either use SQL or some other language that, pragmatically speaking, translates to SQL. But either way, they will learn some DB expression. I'd rather use a standard. Existing familiarity, easier to find docs, support, and is probably more bug-free, etc.
- Moru 3y ago
  And since SQL has existed for so long, chances are that someone already had your problem and has posted the solution somewhere.
- ObscureScience 3y ago
  I can imagine what would be/is valuable is type checked embedded SQL queries.
  - ttfkam 3y ago
    Like Rust's Sqlx? https://github.com/launchbadge/sqlx https://github.com/launchbadge/sqlx
- onlypositive 3y ago
  Another reason to use standard MySQL? ChatGPT is really good at writing, and modifying, SQL queries and the code that injects input into it. You don't really have to write SQL anymore, you just tell chatgpt what you want changed and it works most the time. The times it doesn't, it gets you most of the way there.
  - ttfkam 3y ago
    Not sure "standard" and "MySQL" belong in the same sentence. ;-)
  - mr_toad 3y ago
    > The times it doesn't, it gets you most of the way there. But you have to understand SQL to know that, and to fix it, which defeats the purpose really.
    - onenite 3y ago
      I wouldn’t say that it defeats the purpose really, as it’s a great aid to help us reach the proper solution.
  - deleted 3y ago
    [deleted]
stickfigure 3y ago
> I'd rather learn SQL than whatever custom-flavor-of-ORM-query-language some ORM tool created. Me too! That's why I use an ORM that lets you write queries in SQL, like... Hibernate. This narrative seems to come up frequently. People make (good) arguments against certain features of ORMs and then conclude it's an argument against ORMs in general. The boundary between databases and codebases is very broad. But ultimately you work with objects in your code, and relational tables in your database, so there's going to be some sort of Object Relational Mapper in between.
- iforgotpassword 3y ago
  But... At that point what does hibernate even do for you? You can just use a lighter query wrapper at that point, or almost even roll your own wrapper around jdbc directly. The latter is a bit more work but it might be worth it depending on project since it gives you absolute control. I'll take a query wrapper that's designed so I supply queries directly and it does the work from there (binding to objects) over using hibernate that way any time.
  - kaba0 3y ago
    > depending on project since it gives you absolute control Absolute control to hunt down your own bugs, instead of using something that is an industry standard and any competent programmer jumping to your project can be up-to-speed with it instantly..
    - isbvhodnvemrwvn 3y ago
      Very few developers are competent with hibernate, many fewer than with sql. Writeback cache nature of hibernate makes it very complex, order of operations on the app won't match order of operations in the DB.
    - HelloNurse 3y ago
      Even an "industry standard" framework can get in the way. Given the constraints of executing efficient queries; handling errors and timeouts on the application's terms; and enforcing concurrency and transaction handling policies even a "good" ORM can be more a problem than a solution.
switchbak 3y ago
The problem is the ORM requires you to know its language, the underlying SQL for that database, as well as how the ORM maps to that underlying language. It’s the worst of a leaky abstraction, and like 3x the conceptual overhead. But it’s better because … something something OOP.
- aakresearch 3y ago
  Exactly! The analogy I use is SQL is like two-wheeled motorbike - fast, nimble, elegant. Yes, it may be dangerous. Yes, you may need to wear a helmet. Yes, it cannot carry too much load. But it gets you very quickly very far, if you have skill! Now, ORM sees deficiencies and presents you... two motorbikes welded together side-by-side by some iron sticks. They call it a "car". Four wheels are better than two, right? Two engines can push more load, right? No helmet needed, right? But does it really become a "car", or it is just has most of deficiencies of the motorbike plus some spectacular new ones? And no benefits of a car whatsoever? I run away in disgust.
- hn_throwaway_99 3y ago
  > It’s the worst of a leaky abstraction, and like 3x the conceptual overhead. I really think you hit the nail on the head with this sentence. For example, another commenter said "But the same SQL fanboys who believe every developer ought to memorize tri-state truth tables..." Yes, I think it's fine to argue that the boolean logic with respect to NULL in SQL is a pain in the ass. But ORMs certainly don't hide that from you! The ways DBs treat nulls is a fundamental part of nearly all RDBMSes - if you don't understand that, you're (eventually) going to have a bad time. All ORMs really do is make it harder to understand when you may need to take special null logic into account.
  - paulddraper 3y ago
    Exactly. As unfortunate as those warts are, you can't pretend them away. Might as well be able to see them clearly.
- monero-xmr 3y ago
  “Something something OOP” - you reach enlightenment once you realize OOP itself is an anti-pattern.
yowzadave 3y ago
I agree that ORMs are bad, but disagree in that I think that SQL is also bad--it has this bizarre natural-ish language syntax that is inconsistent and often difficult to reason about, with a huge number of keywords (including many that are noise-only). I would welcome a simple, modern alternative to SQL. I think the fact that people keep building and using ORMs is evidence that SQL is difficult to use.
- hn_throwaway_99 3y ago
  This post about "PRQL" got a ton of upvotes when it was posted on HN last year: https://news.ycombinator.com/item?id=30060784 https://news.ycombinator.com/item?id=30060784 In general, one of the thing I hate most about SQL is "the order of clauses is wrong" (should really start with the FROM clause and end with SELECT, see https://news.ycombinator.com/item?id=21150606 https://news.ycombinator.com/item?id=21150606), and PRQL fixes that.
  - ttfkam 3y ago
    And if that's the biggest perceived problem with SQL, then SQL isn't going anywhere. It can't just be a little better than SQL, especially in terms of syntactic aesthetics; it has to be substantially and provably better than SQL to the point where companies are willing to pay for retraining, folks are willing to buy books and classes about it, and database engine developers have to consider it worthwhile to implement. I don't see PRQL coming close to reaching that bar.
  - zX41ZdbW 3y ago
    It's not a problem with SQL. For example, in ClickHouse, you can write FROM table SELECT ... But this is not a big deal.
    - strokirk 3y ago
      But at that point, it’s no longer SQL, it’s something better. That seems like a very nice point in favor of Clickhouse! But then again, Clickhouse is not a RDBMS, right?

ttfkam 3y ago

Agreed! First time I used the postgres Node library [0], I was sold! [0] https://github.com/porsager/postgres https://github.com/porsager/postgres

B-Con 3y ago

> but I'd rather learn SQL than whatever custom-flavor-of-ORM-query-language some ORM tool created This point is worth emphasizing! When you application carries non-trivial business logic, it will create non-trivial DB access patterns. The developer will either use SQL or some other language that, pragmatically speaking, translates to SQL. But either way, they will learn some DB expression. I'd rather use a standard. Existing familiarity, easier to find docs, support, and is probably more bug-free, etc.

Moru 3y ago
And since SQL has existed for so long, chances are that someone already had your problem and has posted the solution somewhere.
ObscureScience 3y ago
I can imagine what would be/is valuable is type checked embedded SQL queries.
- ttfkam 3y ago
  Like Rust's Sqlx? https://github.com/launchbadge/sqlx https://github.com/launchbadge/sqlx
onlypositive 3y ago
Another reason to use standard MySQL? ChatGPT is really good at writing, and modifying, SQL queries and the code that injects input into it. You don't really have to write SQL anymore, you just tell chatgpt what you want changed and it works most the time. The times it doesn't, it gets you most of the way there.
- ttfkam 3y ago
  Not sure "standard" and "MySQL" belong in the same sentence. ;-)
- mr_toad 3y ago
  > The times it doesn't, it gets you most of the way there. But you have to understand SQL to know that, and to fix it, which defeats the purpose really.
  - onenite 3y ago
    I wouldn’t say that it defeats the purpose really, as it’s a great aid to help us reach the proper solution.
- deleted 3y ago
  [deleted]

stickfigure 3y ago

> I'd rather learn SQL than whatever custom-flavor-of-ORM-query-language some ORM tool created. Me too! That's why I use an ORM that lets you write queries in SQL, like... Hibernate. This narrative seems to come up frequently. People make (good) arguments against certain features of ORMs and then conclude it's an argument against ORMs in general. The boundary between databases and codebases is very broad. But ultimately you work with objects in your code, and relational tables in your database, so there's going to be some sort of Object Relational Mapper in between.

iforgotpassword 3y ago
But... At that point what does hibernate even do for you? You can just use a lighter query wrapper at that point, or almost even roll your own wrapper around jdbc directly. The latter is a bit more work but it might be worth it depending on project since it gives you absolute control. I'll take a query wrapper that's designed so I supply queries directly and it does the work from there (binding to objects) over using hibernate that way any time.
- kaba0 3y ago
  > depending on project since it gives you absolute control Absolute control to hunt down your own bugs, instead of using something that is an industry standard and any competent programmer jumping to your project can be up-to-speed with it instantly..
  - isbvhodnvemrwvn 3y ago
    Very few developers are competent with hibernate, many fewer than with sql. Writeback cache nature of hibernate makes it very complex, order of operations on the app won't match order of operations in the DB.
  - HelloNurse 3y ago
    Even an "industry standard" framework can get in the way. Given the constraints of executing efficient queries; handling errors and timeouts on the application's terms; and enforcing concurrency and transaction handling policies even a "good" ORM can be more a problem than a solution.

switchbak 3y ago

The problem is the ORM requires you to know its language, the underlying SQL for that database, as well as how the ORM maps to that underlying language. It’s the worst of a leaky abstraction, and like 3x the conceptual overhead. But it’s better because … something something OOP.

aakresearch 3y ago
Exactly! The analogy I use is SQL is like two-wheeled motorbike - fast, nimble, elegant. Yes, it may be dangerous. Yes, you may need to wear a helmet. Yes, it cannot carry too much load. But it gets you very quickly very far, if you have skill! Now, ORM sees deficiencies and presents you... two motorbikes welded together side-by-side by some iron sticks. They call it a "car". Four wheels are better than two, right? Two engines can push more load, right? No helmet needed, right? But does it really become a "car", or it is just has most of deficiencies of the motorbike plus some spectacular new ones? And no benefits of a car whatsoever? I run away in disgust.
hn_throwaway_99 3y ago
> It’s the worst of a leaky abstraction, and like 3x the conceptual overhead. I really think you hit the nail on the head with this sentence. For example, another commenter said "But the same SQL fanboys who believe every developer ought to memorize tri-state truth tables..." Yes, I think it's fine to argue that the boolean logic with respect to NULL in SQL is a pain in the ass. But ORMs certainly don't hide that from you! The ways DBs treat nulls is a fundamental part of nearly all RDBMSes - if you don't understand that, you're (eventually) going to have a bad time. All ORMs really do is make it harder to understand when you may need to take special null logic into account.
- paulddraper 3y ago
  Exactly. As unfortunate as those warts are, you can't pretend them away. Might as well be able to see them clearly.
monero-xmr 3y ago
“Something something OOP” - you reach enlightenment once you realize OOP itself is an anti-pattern.

yowzadave 3y ago

I agree that ORMs are bad, but disagree in that I think that SQL is also bad--it has this bizarre natural-ish language syntax that is inconsistent and often difficult to reason about, with a huge number of keywords (including many that are noise-only). I would welcome a simple, modern alternative to SQL. I think the fact that people keep building and using ORMs is evidence that SQL is difficult to use.

hn_throwaway_99 3y ago
This post about "PRQL" got a ton of upvotes when it was posted on HN last year: https://news.ycombinator.com/item?id=30060784 https://news.ycombinator.com/item?id=30060784 In general, one of the thing I hate most about SQL is "the order of clauses is wrong" (should really start with the FROM clause and end with SELECT, see https://news.ycombinator.com/item?id=21150606 https://news.ycombinator.com/item?id=21150606), and PRQL fixes that.
- ttfkam 3y ago
  And if that's the biggest perceived problem with SQL, then SQL isn't going anywhere. It can't just be a little better than SQL, especially in terms of syntactic aesthetics; it has to be substantially and provably better than SQL to the point where companies are willing to pay for retraining, folks are willing to buy books and classes about it, and database engine developers have to consider it worthwhile to implement. I don't see PRQL coming close to reaching that bar.
- zX41ZdbW 3y ago
  It's not a problem with SQL. For example, in ClickHouse, you can write FROM table SELECT ... But this is not a big deal.
  - strokirk 3y ago
    But at that point, it’s no longer SQL, it’s something better. That seems like a very nice point in favor of Clickhouse! But then again, Clickhouse is not a RDBMS, right?