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

301–310 of 354 posts

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

#301

Post by to11mtm »

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.

I mean FWIW Scala has Slick (but then you're dealing with the rest of Scala ecosystem...) and there's Linq2Db on .NET side. Having dealt with all 3 on some level (Slick the least) I would say they are fairly similar in intent (i.e. differences are primarily due to language idioms.)

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

#302

Post by Izkata »

simondotau wrote: post #269
watwut wrote: post #263

Earlier quoted context omitted.

None of your points remove the need to map db values to objects and to fetch related objects.

If you just want to store and retrieve objects, and then store and retrieve "related" objects, what you want is an object store, not a relational database. You can use an ORM to shoehorn it into a relational database engine, but don't fool yourself into thinking that's the same thing as using a relational database engine properly. Obsessively cramming tabular data into objects is often unnecessary, and it bloats the…

Problem is that doesn't work nicely in a one-to-many or many-to-many relationship - fetching it in the original query means deduplicating in the application code, or not fetching it and getting related rows afterwards. And that's one of the things ORMs are really good at.

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

#303

Post by Izkata »

thr0w wrote: post #261
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. …

> Hmm - I need to map these results onto objects I can use. What sql client is going to hand you raw text? > Hmm - wouldn’t it be great if the object tracked changes and could save itself. Lost me there.

> > Hmm - I need to map these results onto objects I can use.

> What sql client is going to hand you raw text?

In python's standard database interface you access columns by index, not name. I figured that's what they're referring to.

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

#304

Post by ChicagoDave »

sgarland wrote: post #189
ChicagoDave wrote: post #182

Earlier quoted context omitted.

Yes and for crud systems relational is fine because you're unlikely to over-complicated your architecture. But when a system starts talking to other systems and its bounded contexts become complex, alternate solutions should be sought. The problem with "schema change", and I did this for decades, is that it's always a massive blocker. In some companies the data architects had to approve and implement schema changes.…

> Document behaviors. Model the system. Let the system decide what data storage it requires. Counterpoint: force the system to use an RDBMS to store data in properly normalized schema, because it’s the only thing guaranteeing that the data will continue to exist as you expect.

This implies nosql data stores are not ACID capable. Mongo is fully capable and DynamoDB is mostly capable.

I would challenge you to look at event driven architectures, CQRS, event sourcing, and how to implement and leverage read models.

It will expand your architecture toolkit.

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

#305

Post by dsego »

simondotau wrote: post #239
dsego wrote: post #231

Earlier quoted context omitted.

But SQL is low level, eg. you can't dynamically pass in filters and construct statements without knowing what the query will be ahead of time. ORMs have query builders that allow you do dynamically construct SQL statement based on parameters, they allow avoiding N+1 queries by doing joins in memory and much more. It's just not possible with vanilla SQL unless you concatenate strings or have multiple versions of the s…

Query builders are a doddle to write, extremely trivial to debug, and generally far easier overall than having to shoehorn data into a structure that your ORM likes. The problem is not that ORMs fail to expose every feature of a particular SQL database. The problem is that they encourage you to model your data in a way that is convenient for the ORM, rather than in a way that is correct for the domain. Any sufficient…

It seems like you are throwing away the baby with the bathwater. I don't think providing 90% of the structure you need is a failed abstraction. And it just doesn't follow that it is pushing you towards sub-optimal structures, not sure where this conclusion comes from. All ORMs I've seen have ways to describe relations between models, even polymorphic types, aggregates, eager loading (to avoid N+1) etc.

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

#306

Post by smw »

rmunn wrote: post #14
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.

Autocomplete is making me lazy. If I don't see what I'm about to type within two or three characters, I feel like the IDE isn't doing its job of helping me. So being able to type `db.Cust` and autocomplete Customers is really nice. I do know SQL, but yes, the language servers usually have a harder time connecting the SQL to my backend code, whatever language it's in, without quite a lot of config fiddling that pretty…

I'm firmly on the ORM side of things, despite knowing SQL very well -- but your IDE/editor can fix this with bare sql. Try using Jetbrains Datagrip or the DB integration in Idea or one of the other language-specific IDEs.

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

#307

Post by Izkata »

imtringued wrote: post #225
delusional wrote: post #206

Earlier quoted context omitted.

As my career progresses, I'm starting to understand just how many developers have trouble comprehending invariants and how they affect system design. If you do not comprehend invariants, then every system is CRUD. The specific danger of CRUD is that all operations are expressible in it. If your system is CRUD, everything goes. A developer who doesn't understand the system's design might be inclined to assume an appli…

This comment reads crazy poorly. Like, if the simple insert, read, update and delete SQL queries are forbidden then what do you guys do all day? Are you really doing inserts exclusively based on the data of another table? You never take user input from a website? You never need to just get a list of data according to a query with some filtering? Honestly I'm not buying it, since the opposite would basically require y…

An invariant is something that must always be true. The most basic example of this is a not-null foreign key, where a value in one table refers to a row in another table and that row in the other table must always exist.

> Are you really doing inserts exclusively based on the data of another table? You never take user input from a website? You never need to just get a list of data according to a query with some filtering?

None of these go against what GP said in any way.

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

#308

Post by nesarkvechnep »

vips7L wrote: post #282
nesarkvechnep wrote: post #171

Earlier quoted context omitted.

This is exactly what happens in a typical Elixir project even though Ecto is a query builder and not an ORM. People define their domain entities as database tables. The result is, from my latest project, you have user and organisation memberships which are a list of membership records. This is carried throughout the application while it should be a hash map of organisation IDs and membership data, so you can check if…

That’s a problem with ecto and not ORMs. A good ORM will be able to do that hashmap mapping.

It’s a problem of philosophy, not tooling.

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

#309

Post by smw »

hatefulheart wrote: post #26
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…

I have seen many ORM enjoyers argue the point about “you can just use SQL!” but I have never once seen an ORM enjoyer allow it, much less do it themselves in an actual codebase. They will time and time again prefer you write 100 lines of Typescript/Python for what could be achieved with 15 lines of SQL.

Even the 'worst' of the ORMs (according to the people in these threads) makes this very easy:

  users = User.find_by_sql( 10
  SQL

  users.first.posts_count
  # => 17

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

#310

Post by Izkata »

webstrand wrote: post #273
mattmanser wrote: post #262

Earlier quoted context omitted.

It's not that your domain is different, it sounds more like you don't know how to use ORMs. ORMs don't have to manage migrations, they don't have to even write into the database. When dealing with a bad database design, it can be a legitimate tactic to use ORMs in read-only mode and have writes still as hand-rolled SQL. You can do database-first ORMs, as well as code-first, where the database design is king, not the…

That doesn't sound at all like any ORM I've ever used. I've struggled in the past because The ones I've used are actively hostile to laying out data in the database in a way not proscribed by the ORMs philosophy. Heck of the ORMs I've used, one didn't support parameterized joins and the other didn't support joins at all. --- It's not usually a DB guy gatekeeping, it's that multiple apps use the same database so layou…

Except for the "multiple ORMs" part which is a level above it, it applies to the only one I've used extensively: Django for python. It has standard defaults, but just about everything overridable, and because models are python objects you can add methods or properties for extra data. There's even ways to define your own field types (the "serialization/de-serialization of individual properties"), which a decade ago people were using to provide json fields through libraries long before it was officially supported.

...and Django was like this 15 years ago when I first started using it. The core design hasn't changed, it just sounds like most other ORMs don't really know what they're doing.

Post reply on HN