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

291–300 of 354 posts

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

#291

Post by win311fwg »

simondotau wrote: post #267
bartread wrote: post #257

Earlier quoted context omitted.

Yeah, exactly. I think the best approach is always to know SQL and know the ORM. Most of the time you’ll be able to simply use the ORM, but every so often you’ll inevitably come up against a situation where a custom query gets the job done better, and you’ll still get the benefits of deserialising to objects that the ORM offers.

As long as you restrict yourself to an ORM-compatible schema, you are restricting the power of SQL available to you. Learning SQL properly means learning to model your data correctly, and this usually makes ORMs a non-starter. Without an ORM you have to write a bit more boilerplate code to interact with the database. But by taking advantage of the power of your database engine, you could potentially avoid writing hug…

ORM is compatible with any schema, but perhaps you are thinking of something like the active record pattern?

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

#292

Post by cultofmetatron »

taylorlunt wrote: post #287
dpedu wrote: post #272

I'm totally on board with the idea that ORMs create a variety of inefficiencies, pain points, and make it really easy to create bad queries or querying strategies. But I use them anyways because the convenience of mapping a row to a code object makes writing programs feel fast and simple. And if you know how ORMs can cause problems and how to watch out for them, you can still get a lot of mileage out of them. That be…

Yes, there is a middle ground. Elixir's Ecto does this well. Database rows map to structs. But it doesn't try to figure out how to mutate the data for you to keep the struct in sync with the database. All mutations are explicit using changesets (which can also be used for other non-database purposes, like validating user input for an API.) There is no implicit preloading of data. You have to explicitly preload. Data…

> Yes, there is a middle ground. Elixir's Ecto does this well.

Ecto is by far the closest thing to a perfect pattern for abstracting over sql that I've ever seen. I WISH other languages would create similar libraries. Its the biggest thing keeping me coming back to elixir for any kind of database project. it just makes sql so ergonomic.

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

#293

Post by win311fwg »

vandahm wrote: post #91

I generally like ORMs but recognize that they have a lot of problems. The most common problem that I've seen is when an ORM makes it easy to select records in a way that looks efficient but really is not. Strictly speaking, this isn't a failure of the ORM itself -- it's the fault of the developer who is using the ORM and also the developer that didn't catch it in code review. But it's a case where the ORM is making w…

> Strictly speaking, this isn't a failure of the ORM itself -- it's the fault of the developer

You've got that backwards. If a tool obscures complexity such that a developer using it could be tricked into thinking their efficient-appearing code is actually inefficient, the problem is the tool. A well-designed tool makes inefficiencies explicit. "You're holding it wrong" is not engineering advice.

> ORMs are good enough for those kinds of projects.

It's all good as long as you have properly abstracted it away from your core application. The trouble with some ORM toolkits is that they encourage you to move database logic into the rest of the application and that's when the messes begin. The old school PHP programmers will know well that SQL in raw doesn't automatically mean proper separation of concerns either, but it is more likely to push you in that direction.

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

#294

Post by teliskr »

Does my opinion on SQL and ORMs matter anymore? What does Claude think about ORMs an SQL? So far Claude seems to be content with my existing patterns of using JPA/Hibernate. We've been having this conversation since the early 2000s. Will we have it next year? Maybe just for fun... to pretend we are still relevant :(

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

#296

Post by mekoka »

simondotau wrote: post #260
iamflimflam1 wrote: post #241

Feels like everyone has to go on the journey. ORMs are bad - I’ll just use SQL. Hmm - I need to map these results onto objects I can use. Hmm - wouldn’t it be great if the object tracked changes and could save itself. I need related/child objects - wouldn’t it be great if I could auto fetch them. …

I think that journey only feels inevitable if you start from the assumption that the application object model is the centre of the system. An alternative journey: Hmm – I should model the data according to the domain, not according to the shape my application objects happen to want. Hmm – maybe “related objects” are not things to auto-fetch, but relationships the database engine is already built to handle. Hmm – now…

Using an ORM should not exempt you from designing your schema around the domain. If anyone thinks it's the case they're either using the ORM wrong, or using the wrong ORM, or perhaps creating the wrong ORM.

Similarly, designing your schema to match the domain does not necessarily grant you the productivity boons of an ORM.

Having (ab)used Postgres with and without ORM, I've never had a situation where the latter imposed any kind of design decisions on the schema. They're orthogonal concerns. Itself, the choice of using an ORM tends to be motivated by experience with certain requirements in the business logic. I love SQL, but when having to deal with API resources and their various representations, marshaling, validation, options, etc, it's difficult -- and to say the least, impractical -- to stay principled to the "no-ORM" and "raw-SQL" mottos.

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

#297

Post by win311fwg »

Arch-TK wrote: post #98
valzam wrote: post #7

The big problem is that raw SQL has pretty bad type inference and linting support in most editors. A query builder can still give you a lot of type safety benefits.

A query builder is not an ORM. ORMs build queries for you, but a query builder does not need to be an ORM.

ORMs do not inherently build queries. They only provide data transformations between relations (i.e. rows and columns) and objects. Hence the literal name: Object relation mapping. You can absolutely have ORM without query building just as much as you can have query building without ORM.

Sometimes ORMs and query builders are combined into a higher order system, such as what is described by the active record pattern. This might be what you are actually thinking of instead?

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

#298

Post by sarchertech »

cultofmetatron wrote: post #292
taylorlunt wrote: post #287

Earlier quoted context omitted.

Yes, there is a middle ground. Elixir's Ecto does this well. Database rows map to structs. But it doesn't try to figure out how to mutate the data for you to keep the struct in sync with the database. All mutations are explicit using changesets (which can also be used for other non-database purposes, like validating user input for an API.) There is no implicit preloading of data. You have to explicitly preload. Data…

> Yes, there is a middle ground. Elixir's Ecto does this well. Ecto is by far the closest thing to a perfect pattern for abstracting over sql that I've ever seen. I WISH other languages would create similar libraries. Its the biggest thing keeping me coming back to elixir for any kind of database project. it just makes sql so ergonomic.

As someone who works with an 8 year old 500k LOC elixir codebase with millions of users, I hate Ecto so much. The thing I hate most is that there are 2 different syntaxes.

But a close second is that it encourages composition in situations where duplication is the right choice. Having your sql query spread across 7 files makes tracking down bugs and performance issues (and fixing them) incredibly difficult.

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

#299

Post by 9rx »

simondotau wrote: post #249
gmac wrote: post #247

Earlier quoted context omitted.

There's a middle ground between ORMs and raw SQL, especially if you're using a strongly typed language. My library Zapatos[1] is one example among several. [1] https://jawj.github.io/zapatos/

That does look like a compelling tool specifically because it isn't really an ORM. It seems more like an ergonomics layer for SQL within that particular language. It looks decent because the database schema remains the source of truth, and the code adapts to it — not the other way around. I think ORMs mostly exist because most programming languages tend to lack an elegant way to write SQL and interact with results. S…

> They do not need an ORM.

What you do need is some kind of boundary mapping layer so that your application isn't tightly coupled to the database. That might be a an RRM instead, but if you are going to all the trouble of adding an RRM, why not an ORM? What's the difference, really?

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

#300

Post by to11mtm »

dpedu wrote: post #272

I'm totally on board with the idea that ORMs create a variety of inefficiencies, pain points, and make it really easy to create bad queries or querying strategies. But I use them anyways because the convenience of mapping a row to a code object makes writing programs feel fast and simple. And if you know how ORMs can cause problems and how to watch out for them, you can still get a lot of mileage out of them. That be…

The happiest middle ground I've found in .NET has been LinqToDb.

It's more of a Micro ORM, -but- has a Linq DSL, as well as DSLs for lots of DB bits. CTEs, Window functions, Bulk copy, 'treat this in memory collection as an input rowset', certain DB Specific bits... and if you need some special sauce to deal with brownfield jank [0] it's very easy to wire-up custom SQL bits into your queries via attributes if needed.

If you use method syntax rather than linq query syntax, you will have minimal surprises with the SQL generated. Typically if it does generate something I didn't expect, I dig in and what it did was indeed both correct and better than what I was trying to do anyway.

[0] - Fun nasty case I ran into on a brownfield project; 'If this number has a decimal point, it is a direct percentage rate. If the number does NOT have a decimal point, it is the FK to a lookup table that has the percentage rate'

Post reply on HN