Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What ORMs have taught me: just learn SQL (2014)

wozniak.ca

Post reply on HN
Print view View original

211–220 of 354 posts

Re: What ORMs have taught me: just learn SQL (2014)

#211

Post by ako »

bluefirebrand wrote: post #29
noisy_boy wrote: post #8

As someone who started their programming journey with SQL, it just feels so odd hearing about learning SQL being presented as an useful option. I get it, it just feels odd. SQL was considered table stakes in the financial IT world - if you said you didn't know SQL, people would look at you funny.

It's very strange too. You can learn something like ~90% of useful SQL in an afternoon. The remainder is stuff that you only really need for extremely performance sensitive operations

I think the hard part is not the syntax itself but the shift in thinking: instead of procedural state manipulation expressing the desired end result in declarative set based relation algebra. I see developers struggling with breaking down complex queries in (inline) views / CTEs, thinking they need parameters, when things can be expressed as a queries on another query. Complaining about the lack of reusability, but not knowing about views.

Re: What ORMs have taught me: just learn SQL (2014)

#212

Post by Exoristos »

Kon5ole wrote: post #168
tengbretson wrote: post #100

I don't disagree with any of the major gripes people have with orms and I find SQL to be much cleaner in a lot of circumstances. That being said, if orms didn't force you to explicitly define your domain models about 60% of developers would simply never do it. And you would see differently structured, ad-hoc interfaces defined all over the code base completely entangled with whatever action they are trying to perform…

>ORMs being a forcing function for domain modeling is enough benefit for me that it outweighs all of their obvious limitations. That was a surprising take! I know only a few ORM's but it seems they end up just adding another layer of DTO objects that are entirely separate from the domain classes anyway. So best case the ORM is just a detour for a good domain model. Worst case it creates a weird database-contaminated…

Why is your database so different from your domain?

Re: What ORMs have taught me: just learn SQL (2014)

#213

Post by andy_ppp »

This is one of numerous things Elixir and Phoenix get right with the database layer, which on the surface looks like an ORM but is in fact a set of clever functions that write SQL using Elixir macros, as well as a system for validation and minimal changes to data being passed to said SQL.

I’m surprised more languages don’t copy this because it’s exactly what I want rather than loads of complexity that eventually always breaks down.

Re: What ORMs have taught me: just learn SQL (2014)

#214

Post by Foobar8568 »

miohtama wrote: post #199
tengbretson wrote: post #100

I don't disagree with any of the major gripes people have with orms and I find SQL to be much cleaner in a lot of circumstances. That being said, if orms didn't force you to explicitly define your domain models about 60% of developers would simply never do it. And you would see differently structured, ad-hoc interfaces defined all over the code base completely entangled with whatever action they are trying to perform…

SQL is pretty shitty language to write modular, reusable and easy to read code.

It's easy to read SQL code as long as the person writing the query doesn't resort to "hack" the planner. Now to make that reusable....That's another beast and most often will defeat the purpose of writing pure SQL in the first place, let's put a OR there, let's call several queries, let's screw the data model.

Re: What ORMs have taught me: just learn SQL (2014)

#216

Post by xigoi »

hn_throwaway_99 wrote: post #48
stephen wrote: post #15

I'm admittedly an ORM apologist [1], but a few of his points articulated as "deal breakers" aren't that bad imo: - "the pernicious use of foreign keys [...] links between classes are [...] foreign keys" ==> that just sounds like schema normalization, which is usually a good thing? - "bending over backwards [...] to generate SQL that runs efficiently" ==> the huge majority of ORM-driven queries are "select * from tabl…

> "bending over backwards [...] to generate SQL that runs efficiently" ==> the huge majority of ORM-driven queries are "select * from table where id in ..."; for the queries that are more complicated than that, then yes use SQL! That's allowed! This is exactly why I hate ORMs. As I always put it "ORMs make the easy stuff slightly easier, and they make the harder stuff way harder". If you're just using an OEM for the…

> If you're just using an OEM for the "select * from table where ID in ...", then you're saving practically nothing by using an ORM

You’re saving hundreds of lines of repetitive boilerplate code. Do you enjoy writing something like

  users = [
    User(name=name, color=color)
    for name, color
    in db.query("SELECT name, color FROM user")
  ]
over and over?

Re: What ORMs have taught me: just learn SQL (2014)

#217

Post by asQuirreL »

andy_ppp wrote: post #213

This is one of numerous things Elixir and Phoenix get right with the database layer, which on the surface looks like an ORM but is in fact a set of clever functions that write SQL using Elixir macros, as well as a system for validation and minimal changes to data being passed to said SQL. I’m surprised more languages don’t copy this because it’s exactly what I want rather than loads of complexity that eventually alwa…

> on the surface looks like an ORM but is in fact a set of clever functions that write SQL

Honest question -- what's the difference?

Usually the problems with ORMs stem from the fact that they are exactly clever functions that write SQL. The cleverness abstracts features of SQL that are important for performance and also makes it easy to do things that are bad for performance.

I'm not saying that the ecosystems you mentioned aren't doing something different, I just don't know what it is from how you've described their DB layers.

Re: What ORMs have taught me: just learn SQL (2014)

#218

Post by victorbjorklund »

andy_ppp wrote: post #213

This is one of numerous things Elixir and Phoenix get right with the database layer, which on the surface looks like an ORM but is in fact a set of clever functions that write SQL using Elixir macros, as well as a system for validation and minimal changes to data being passed to said SQL. I’m surprised more languages don’t copy this because it’s exactly what I want rather than loads of complexity that eventually alwa…

I think C# has a similar syntax for building queries in linq.

Elixir

from u in User, where: u.age >= 18, select: u

C# var adults = from u in users where u.Age >= 18 select u;

Re: What ORMs have taught me: just learn SQL (2014)

#219

Post by andy_ppp »

asQuirreL wrote: post #217
andy_ppp wrote: post #213

This is one of numerous things Elixir and Phoenix get right with the database layer, which on the surface looks like an ORM but is in fact a set of clever functions that write SQL using Elixir macros, as well as a system for validation and minimal changes to data being passed to said SQL. I’m surprised more languages don’t copy this because it’s exactly what I want rather than loads of complexity that eventually alwa…

> on the surface looks like an ORM but is in fact a set of clever functions that write SQL Honest question -- what's the difference? Usually the problems with ORMs stem from the fact that they are exactly clever functions that write SQL. The cleverness abstracts features of SQL that are important for performance and also makes it easy to do things that are bad for performance. I'm not saying that the ecosystems you m…

No ORMs try to make the concept of SQL hidden, in Elixir you will not get very far if you don’t understand the SQL you’re trying to write. So I’d probably say nothing is really being hidden from you - as little magic as possible.

https://ecto.hexdocs.pm/Ecto.Query.html

Re: What ORMs have taught me: just learn SQL (2014)

#220

Post by victorbjorklund »

asQuirreL wrote: post #217
andy_ppp wrote: post #213

This is one of numerous things Elixir and Phoenix get right with the database layer, which on the surface looks like an ORM but is in fact a set of clever functions that write SQL using Elixir macros, as well as a system for validation and minimal changes to data being passed to said SQL. I’m surprised more languages don’t copy this because it’s exactly what I want rather than loads of complexity that eventually alwa…

> on the surface looks like an ORM but is in fact a set of clever functions that write SQL Honest question -- what's the difference? Usually the problems with ORMs stem from the fact that they are exactly clever functions that write SQL. The cleverness abstracts features of SQL that are important for performance and also makes it easy to do things that are bad for performance. I'm not saying that the ecosystems you m…

The thing is that in Ecto, everything is structured around the actual underlying data. Rather than some abstract objects and stuff like that.

query = from u in User, where: u.age > 18

Repo.all(query)

And there is no magic (At least very little). For example, if you wanna access something that is in another table, for example, you're on a user and you wanna access their posts in many frameworks, if you try to read their posts, they would be automatically loaded from the database but in Ecto, you need to explicitly preload them. That avoids accidental and n+1 problems because you can plan your queries more. You're not gonna trigger a lot of queries without realizing it.

Post reply on HN