Live data from Hacker News

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

wozniak.ca

121–130 of 654 posts

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

#121
On a recent project, it was a weird inversion in terms of access... in order to keep the middle tier thin, and meet requirements that all data access happen through stored procedures... we pretty much standardized an interface with one input parameter (@json) and two output parameters (@result, @errorResult). In the end, all input/output was JSON and the database handled all data internally.

I don't really like it much, but it did make the API service super thin, and the "database guys" were happy to do it all in SQL. Of course, testing that beast isn't so fun, and there be dragons...

In the end, I tend to favor creating APIs with scripted languages that require less translation to work with the database side, and structure responses to match the expected data layouts for the API side. With node, I usually create/use a simple abstraction...

    var result = await db.query`SELECT ... WHERE foo=${bar}`;
    or
    var result = await db.exec('sprocname', {...});
In either case, not really a need for a formal ORM here.

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

#122
Me thinks someone needs to have a go at maintaining a 2Mloc accounting package built using only embedded SQL statements and stored procedures, including migrating the whole mess between major database vendors.

I guess one advantage is you have to learn, it but I really prefer some kind of ORM for more mundane repetitive CRUD. More to get a structured (ha!) interface between the database and the application than for the convenience.

I do wish most of them would stop insisting on putting the cart in front of the horse and make code the primary representation.

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

#124

I think there's often an underlying confusion between different tools and what they are supposed to do. An ORM - as the acronym says - is helpful to map database records to objects in the system. The meaning of the acronym already says that an ORM is not really designed for scenarios like aggregations and reporting. Within those contexts, you don't normally reason in terms of list of "objects" and "relationships" bet…

Query builders can be so good at making it easy to work with the database ... the popularity of ORMs over query builders is a really big collective reasoning failure in my opinion.

With a good query builder in hand - it is very unclear to me why anyone would ever want to use an orm.

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

#125

On a recent project, it was a weird inversion in terms of access... in order to keep the middle tier thin, and meet requirements that all data access happen through stored procedures... we pretty much standardized an interface with one input parameter (@json) and two output parameters (@result, @errorResult). In the end, all input/output was JSON and the database handled all data internally. I don't really like it mu…

It was not the first time I heard the requirement about "all data access happen through stored procedures", and I find it ludicrous.

Does anyone know how such a paradigm came to exist? What problem is this solving?

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

#126

On a recent project, it was a weird inversion in terms of access... in order to keep the middle tier thin, and meet requirements that all data access happen through stored procedures... we pretty much standardized an interface with one input parameter (@json) and two output parameters (@result, @errorResult). In the end, all input/output was JSON and the database handled all data internally. I don't really like it mu…

the sprocname approach gives you an option to only grant your app user execute permissions on sps and thats it. (much tighter from security standpoint)

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

#128
post #125

On a recent project, it was a weird inversion in terms of access... in order to keep the middle tier thin, and meet requirements that all data access happen through stored procedures... we pretty much standardized an interface with one input parameter (@json) and two output parameters (@result, @errorResult). In the end, all input/output was JSON and the database handled all data internally. I don't really like it mu…

It was not the first time I heard the requirement about "all data access happen through stored procedures", and I find it ludicrous. Does anyone know how such a paradigm came to exist? What problem is this solving?

Security, decoupling calling code from db schema

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

#129

Earlier quoted context omitted.

Wait, this is displayed gray. It got downvoted???

Maybe it's because the problem isn't directly caused by ORMs but just a very poor usage of ORMs. The same problem would have existed if a loop was written to perform the same query.

Sure you can make arguments one way or another regarding if a hand-written block of SQL would have the same flaw, but if an experienced DBA or developer writes it, I would bet on their output way over anything an ORM outputs.

If you consider the software development process as a whole, the explicit SQL approach intrinsically guarantees additional scrutiny of the actual SQL statements. If you hide all of this behind an ORM, all that is seen during code review time is some beautiful POCO model with a few extra IEnumerables thrown on it. No one is paying attention to the man behind the curtain and the horrible join that was just created automagically.

Perhaps the answer is to just log and profile all the ORM generated SQL - Sure, but if you could look at the ORM's output (which in some cases is abusively large) and quickly determine if its good or not, why not just write it yourself and be 100% sure from the start?

Post reply on HN