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

401–410 of 654 posts

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

#401

Post by revscat »

ryangittins wrote: post #315
725686 wrote: post #37

Each time I see someone complain about ORMs I remember Greenspun's tenth rule[1], which adapted to ORM would be: "Any sufficiently complicated program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a decent ORM." ORMs are hard for a reason. Using an ORM doesn't mean you can't or shouldn't use plain SQL where the situation calls for it. You can mix and match perfectly fine. [1] ht…

> You can mix and match perfectly fine. Thank you! This seems like one of those topics where people often feel the need to pick a side for some reason. I've often heard criticism to the effect of, "people only use ORMs because they don't know SQL. Learn SQL!" It's seemingly impossible to convince these people that ORMs are fantastic for reducing boilerplate code and they can coexist right next to raw SQL for problems…

This.

Earlier in my career I made a point to deep dive into SQL. Long story short: I realized that there are a lot of very good reasons to limit the amount of raw SQL in your application that have nothing to do with familiarity.

SQL is just a bad language, and it’s unfortunate that we’re still stuck with it, basically unchanged, decades after its introduction.

For me, it’s almost as anachronistic as COBOL.

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

#402

Post by troxwalt »

vips7L wrote: post #378
philwelch wrote: post #308

Earlier quoted context omitted.

Yes, yes, yes. Why is this the case? 1. If you are doing anything interesting, people are going to ask questions about what you are doing, and the best way to answer those questions is going to be by querying your database. 2. One day you might want to rewrite some of your service/s, split them into microservice/s, etc. At that point, there will be a minimum of two services talking to your datastore: the legacy servi…

The simple solution to 1 is to never allow direct database access. Api only.

What do you mean by this? What other way , other then digging right into the data is there to access the database? Isn't it all through APIs?

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

#403

Post by xwolfi »

vips7L wrote: post #378
philwelch wrote: post #308

Earlier quoted context omitted.

Yes, yes, yes. Why is this the case? 1. If you are doing anything interesting, people are going to ask questions about what you are doing, and the best way to answer those questions is going to be by querying your database. 2. One day you might want to rewrite some of your service/s, split them into microservice/s, etc. At that point, there will be a minimum of two services talking to your datastore: the legacy servi…

The simple solution to 1 is to never allow direct database access. Api only.

Never even tell you have one, else the founder will pat on the back of one of your most junior dev and ask if he can give access to the db to that other team who needs to make money :D

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

#404

Post by shkkmo »

taffer wrote: post #302
fastball wrote: post #284

Earlier quoted context omitted.

What ORM do people use that influences the structure of their database? The ORM I'm currently using the most can do whatever I need with my Postgres DB. Also, the ORM allows me to specify models that are not only used for structuring the database, but also for validation of incoming JSON requests and easily serialize queries back to JSON.

> What ORM do people use that influences the structure of their database? Hibernate and JPA encourage designing your domain classes first and then generate the DDL from that. > Also, the ORM allows me to specify models that are not only used for structuring the database, but also for validation of incoming JSON requests and easily serialize queries back to JSON. Postgres has great JSON support, does the ORM something…

> Hibernate and JPA encourage designing your domain classes first and then generate the DDL from that.

This is a feature, not requirement or need of the ORM. It seems pretty silly to let the existence of a feature prevent you from making designing the structure of your DB correctly.

> does the ORM something with JSON that Postgres cannot do?

Postgres's json functionality is used for manipulating and querying data stored in the DB.

I believe the poster is talking about deserializing and validating json from REST requests and serializing json for REST responses using the mapping defined for the ORM.

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

#406

Post by bitexploder »

setr wrote: post #255
mapgrep wrote: post #205

Earlier quoted context omitted.

Ya I’ve heard this one a lot. It’s kind of funny to say and does humorously underline the complexity of the problem but people take it seriously. So to take it seriously for a second: There was no good reason to be in Vietnam; even taking the stated rationale as a given, which many people did not, it was a concern many levels removed from the actual safety or functioning of American society. ORMs in contrast achieve…

Tbh you could easily claim that the explicit goal, mapping to objects, is incorrect. The real value is to reduce the damage of the SQL language itself — the unnecessarily ordered clauses, the arbitrary inconsistencies in syntax, the worthless parser errors, the lack of any static typechecking — which cause so much code bloat and debug headaches. There are two reasons to use the ORM: to not learn SQL, and to generate…

I have found the best ORMs don’t hide their SQLness much. SQLAlchemy is pretty great, but you don’t get full use out of it unless you have your arms around SQL itself. When you use an ORM to cut down on chores it’s great. When you use an ORM to avoid your datastore and it’s idiosyncrasies it is worth taking a long hard look at why :)

Most of the ORM interactions are well formatted code that don’t hide the datastore much. As long as you let the ORM map in objects and it’s performant, life is alright. When the ORM starts running the show there may be no coming back.

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

#407

Post by Trisell »

ct520 wrote: post #354
scarface74 wrote: post #338

Earlier quoted context omitted.

One of the most popular Micro ORMs for C# is Dapper which is used by Stack Overflow. There is no real abstraction. You write standard SQL and it maps your recordset to an object. You know exactly what code is running. There are extensions that will take a POCO object and create an insert statement and I believe updates, but where ORMs usually get obtuse and do magic are Selects. It’s hard to generate a suboptimal Ins…

So.. pattern I see emerging. Use orm for the common stuff and execute sql for complicated queries (like reports)

That’s how I’ve done it on my last two projects. We used TypeORM for the standard repeated simple queries, and then wrote custom SQL for our complicated queries that the ORM failed at and then just executed them with the ORM. It was really nice and made for easier table refactors because we didn’t have to go through and audit every query that was calling that table.

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

#408

Post by calvinchengx »

This is a false dichotomy isn't it?

Most ORMs allow the developer to bypass the ORM and use raw SQL when the need arises, so I don't really see the point of avoiding ORMs.

Across the lifespan of a project, in early stages, a developer would discover that ORMs provide code maintainability and depend heavily on it.

As project requirements increase in complexity, raw SQLs will be required because of performance reasons.

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

#409

Post by setr »

Noumenon72 wrote: post #353
noisem4ker wrote: post #259

Earlier quoted context omitted.

Something like jOOQ? https://www.jooq.org

Ye. Static typechecking is the only thing in his list that I really care about, since you can "git gud" at SQL and not be bothered by the syntax/ordering/parser concerns. jOOQ is exactly what I want to bridge the gap between Java and the DB.

The ordering is always a problem, because your logic may not follow it. Eg if your set of conditions apply to multiple queries, then you might know your where conditions before you know your select/from clauses.

So instead of building up your sql string in a straightforward fashion, you need to have at minimum an abstraction that delays construction.

You get lead into vietnam as almost a direct result of SQL’s context-sensitive clauses.

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

#410

Post by shkkmo »

gernak wrote: post #394
scarface74 wrote: post #355

Earlier quoted context omitted.

Eventually if you’re working with an object oriented language or if you have to convert the result to JSON, you’re going to have to convert one paradigm to another. Unless you’re programming in assembly, everything you do is being converted into another paradigm that is what every compiler and interpreter does.

You can only use a fraction of the features of a SQL database when you use an ORM because they don't translate to the new paradigm. When I am using a high level programming language, it is merely helping me do things like manage memory. I am not constantly wishing I could drop down and work with pointers and so on. It is a foundational paradigm that builds on the top of the one before it. ORMs just present a differen…

> You can only use a fraction of the features of a SQL database when you use an ORM because they don't translate to the new paradigm

How does an ORM prevent you from using any SQL features?

When you do the sorts of complicated things that are out of scope for an ORM, you do them in SQL. I don't see any incompatibility.

Post reply on HN