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

171–180 of 354 posts

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

#171

Post by nesarkvechnep »

sdevonoes wrote: post #167
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…

I understand you mean “data” model instead? Perhaps for simple cruds, there’s no much point in differentiating between the data model and the domain model. For more complex scenarios, having orm concerns leak into the domain model is not nice

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 a user is a member of an organisation in constant time. Of course keeping ourselves coupled to the database representation is easier than defining a view, for example, which takes care of presenting the data in a useful form for the application.

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

#172

Post by ChicagoDave »

zsoltkacsandi wrote: post #62
ChicagoDave wrote: post #41

ORMs taught me that relational databases are an operational anti-pattern. NoSQL for operational data storage is more efficient and cost effective. ORMs were a regression test that exposed unnecessary complexity.

I’ve never seen any reliable service built on a NoSQL store as a primary data store. If data consistency and not losing customer data important for you, RDBMS are just fine.

Data consistency was solved in Mongo and DynamoDB years ago. CQRS is a better pattern. Read Models out of analytics (relational) data stores are better for dashboards. I stopped being "SQL First" ten years ago and never looked back. Saved clients time, money, and improved maintenance and eased feature additions.

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

#173

Post by arwhatever »

ibejoeb wrote: post #129
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…

Wouldn't you consider defining the schema doing the domain modeling? I think ORMs do too much. I want to control the querying, or, more precisely, I want to control the SQL that goes to the planner. The good ones largely do allow for this, but I can't think of one that has innate support for vendor-specific features. What I do appreciate is that they handle the boilerplate like managing connections, preparing stateme…

> Wouldn't you consider defining the schema doing the domain modeling?

To an extent, yes.

But to the extent that a so-called impedance mismatch exists, this is going to put your domain model on the faraway/difficult side of that impedance mismatch.

And will result in your domain model existing in an (on average) less expressive language which is more difficult to test.

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

#174

Post by nodamage »

People have been making these same arguments for decades and at this point I'm convinced they are all based on the same strawman:

That ORM's absolve you from having to learn SQL.

Once you understand that was never actually true to begin with you can treat the ORM as a tool that simply helps you generate repetitive boilerplate queries and hydrates result rows back into objects for you.

Furthermore, if your objects are long lived (e.g. client-side apps) then ORMs offer you helpful features like identity mapping, unit of work, and change tracking/events.

I'm also convinced most of the people poo-pooing on ORMs just haven't worked on problems where these kinds of features are useful. I mean, if you're writing a reporting tool that just queries the database and dumps the result to a table then yeah you might not need an ORM for that. It doesn't mean that ORMs don't solve useful problems for other use cases though.

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

#175

Post by hparadiz »

dools wrote: post #170
hparadiz wrote: post #74

Earlier quoted context omitted.

That's a query writer. Not an ORM.

No, it's an ORM because it gives you object based iteration over your query (and the ability to use custom classes for those objects, you just don't have to create classes for every single thing if you don't need them). EDIT: oh wait looks like I never got around to implementing the ability to use custom classes :) this is still in the to do section: come up with a good "mix in" style to cast the objects returned fro…

You are outputting generic QueryRow classes in your code for all results. That doesn't make it an ORM.

By your definition PDO would qualify https://www.php.net/manual/en/class.pdorow.php

Here's a full report for you https://gist.github.com/hparadiz/a1fe30e88dbbe070878a7ea4f72...

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

#176

Post by setr »

nodamage wrote: post #174

People have been making these same arguments for decades and at this point I'm convinced they are all based on the same strawman: That ORM's absolve you from having to learn SQL. Once you understand that was never actually true to begin with you can treat the ORM as a tool that simply helps you generate repetitive boilerplate queries and hydrates result rows back into objects for you. Furthermore, if your objects are…

The problem with ORMs are

1. They pretend SQL is standardized, and support a heavily reduced featureset for any given database as a result

2. They leave awkward holes in their abstraction, leading to psychotic behaviors like N+1 and implicit type coercions to helpfully break your indexes silently

3. They make simple queries simple, and hard queries absolutely revolting

4. You end up not wanting to use the objects directly anyways, so you end up with object-object-relation, needing a mapping layer from your database-object to your business-objects, which also defeats most of the benefits from change-tracking

5. The generated SQL is periodically utterly nuts, so you have to review every generated query anyways

6. You probably dont want to actually use any of the OOP mapping features like inheritance in your DB

The correct answer is to use a query builder + database model, enabling most queries to be written with some degree of type-safety, and minimizing the abstraction from SQL itself, and toss out the rest of the featureset

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

#177

Post by hoppp »

ChicagoDave wrote: post #172
zsoltkacsandi wrote: post #62

Earlier quoted context omitted.

I’ve never seen any reliable service built on a NoSQL store as a primary data store. If data consistency and not losing customer data important for you, RDBMS are just fine.

Data consistency was solved in Mongo and DynamoDB years ago. CQRS is a better pattern. Read Models out of analytics (relational) data stores are better for dashboards. I stopped being "SQL First" ten years ago and never looked back. Saved clients time, money, and improved maintenance and eased feature additions.

It's sort of about your skills, if you are better at NoSQL then use that. But it doesn't mean that your experience is universal.

Relational databases are incredibly flexible even if you have a NoSQL mindset, you can do data modelling like that in Postgres too with jsonb data types.

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

#178

Post by geophile »

jghn wrote: post #116
geophile wrote: post #97

I used to love ORMs so much that I built one for Java, in the early 90s, and it was one of the main offerings of a startup that I joined. I have come around 180 degrees. My rethink started when a developer at a Wall Street bank said: having Oracle on my resume is valuable. Having your ORM on my resume is not. And then there’s the “now you have two problems” dynamic. You not only have to write high-performing queries,…

> built one for Java, in the early 90s So was your ORM for Oak? Java didn't hit the public sphere until 1995 IIRC

No it was Java. Sorry, it was late 90s.

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

#179

Post by Charon77 »

ElectricalUnion wrote: post #150
sandreas wrote: post #106

Earlier quoted context omitted.

Additionally I think the migration management that most ORMs support are also a good thing. Defined and type-safe forward and backward strategies are helpful in most cases, especially if you'd like to support more than one DBMS. I personally think that ORMs are good for management and simple CRUD cases, QueryBuilders are good for managing more complex queries while still being secure / type-safe and for everything el…

> ORMs are good for management and simple CRUD cases I for one think that "simple CRUD cases" is bullshit, those applications don't exist. In practice, System-of-Records systems are rare. (and should be, their value are inversely proportional of how many of those you have in your overall system). Because if it was "just simple CRUD", one would use the database directly? Databases are already capable of handling CRUD…

Agreed. Simple CRUD is something that only shows up in the beginning of the project, everyone was told to use ORM for that purpose, business grow, and you had awkward requirements that require complex ORM features which might exist but requires deep dive into ORM library's corner case, or just straight not possible and makes you bang your head wishing you'd write SQL instead where it would have been obvious what to write.

The only good thing about ORM is the type safety, but I find rust's sqlx or java's jooq to be hitting the sweet spot.

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

#180

Post by bluefirebrand »

jcgl wrote: post #75
marcosdumay wrote: post #52

Earlier quoted context omitted.

AKA making the easy parts easier while making the difficult parts harder.

No? ORMs don’t preclude writing raw SQL, so it’s just making the easy parts easier while leaving the difficult parts the same.

The ORMs I've tried tend to produce some pretty specific table structures that are a pain in the ass to work with outside of the ORM, imo

One of the sticking points I've found in the past is if I create a new table outside of the ORM, it doesn't know how to use it. Then if I try to add it to the ORM's model it doesn't use the existing table, it creates a conflict. Annoying stuff like that

Post reply on HN