What ORMs have taught me: just learn SQL (2014) • Hacker News Board

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

#251

Post by bigpeopleareold » Mon, Jun 27, 2016, 12:02 PM UTC

titanomachy wrote: post #64

PeCaN wrote: post #47

Earlier quoted context omitted.

> If you're not using an ORM, then you ultimately end up writing one. I disagree with this. A lot of things people use ORMs for are rather easily solved with stored procedures, especially in Postgres where you can write stored procedures in Perl, Ruby, etc. Validations, “fat models”, etc are all managed with SQL easily (and this means you get that functionality from _anywhere you access the database_, not just from y…

How do you manage version-control on stored procedures? Can they be checked in with the rest of the application logic?

I have found Sqitch (http://sqitch.org) to be a useful solution.

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

#252

Post by nickpeterson » Mon, Jun 27, 2016, 12:16 PM UTC

Something1234 wrote: post #69

nickpeterson wrote: post #44

Earlier quoted context omitted.

Also Java and C# developers often produce bad SQL procedures because they tend to think procedurally about problems.

What would be the better thought process for writing sql procedures? It seems like PL/SQL is fairly procedural.

The rule of thumb would be, use SQL statements to model and execute business logic, not cursors/variables. While the execution is still procedural, the goal is to make all the decisions 'at once' rather than explicitly looping. Behind the scenes a similar set of steps are taken, but the dbms is free to perform the operations as it sees fit.

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

#253

Post by ourmandave » Mon, Jun 27, 2016, 12:16 PM UTC

kerkeslager wrote: post #176

manigandham wrote: post #138

Earlier quoted context omitted.

> If there's a large object/relational impedance mismatch, then either the objects or the relational DB are a poor fit for the problem you're trying to solve. Why? You're just making that assumption but the fact is that relational databases and the normalized storage of data is completely different from the way OO languages deal with rich nested objects. And there's nothing wrong with that mismatch because there will…

I suspect you're viewing my previous comment as a criticism of ORMs. I tried to make it clear that it was not a criticism of ORMs. It's more a criticism of people who try use ORMs to whitewash a bad design or get around a problem that relational databases can't solve. Relational databases lend themselves to a very specific way of structuring data, and if you don't structure your data that way or your data can't be st…

Nobody uses a screwdriver to saw wood. But they're great as replacement paint stirrers and hole punches.

That's my bad ORM misuse analogy.

As a maintenance programmer, it really fries my bacon when I find all the screwdrivers next to the old paint cans.

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

#254

Post by bigpeopleareold » Mon, Jun 27, 2016, 12:17 PM UTC

spacecowboy_lon wrote: post #212

fishtoaster wrote: post #31

Earlier quoted context omitted.

I completely agree. 90% of the queries in my app are no more complex than selecting from a table with a simple condition. I definitely find users = User.where(has_foo: true).limit(10) to be a lot more readable than rows = connection.exec_query("SELECT * FROM users WHERE has_foo=true LIMIT 10") users = rows.map { |row| User.build(row) } (And that's an example with no user-provided input) Likewise, any app of sufficien…

No professional developer should EVER use Select * in working code.

At least it is an obvious fix. :) The AR example/solution would tend to just assume you want all the fields. To those naive of how AR behaves, it isn't obvious.

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

#255

Post by JustSomeNobody » Mon, Jun 27, 2016, 12:23 PM UTC

eudox wrote: post #86

woah wrote: post #77

Earlier quoted context omitted.

Don't parameterized queries provide all the safety one might need?

Parameterized queries are to prevent injection. They don't tell you, at compile time, when you're building an invalid/unrepresentable SQL query.

No, but your unit tests should catch bad queries and then you're good to go.

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

#256

Post by MustardTiger » Mon, Jun 27, 2016, 12:40 PM UTC

StevePerkins wrote: post #34

Ten years ago, there was a blog post every other week bemoaning ORM's. Ten years ago, those posts often had merit. In 2016, this sentiment is outdated. A few points: 1. If you think that using an ORM means you don't have to learn SQL, then you're going to have a bad time. This is where most of the bad press originates... from people who never really learned SQL or their chosen ORM. An ORM provides type checking at yo…

>If you're not using an ORM, then you ultimately end up writing one. And doing a far worse job than the people who focus on that for a living.

I don't understand why people keep repeating this myth. I do not use an ORM. I did not write one, or anything resembling one. I have absolutely no problems with accessing my database from my applications.

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

#257

Post by vbezhenar » Mon, Jun 27, 2016, 12:59 PM UTC

Hibernate is a very complex library. SQL+JDBC on the other hand is easy (JDBC is tedious, some complex SQL might be hard, but generally it's easy). On the other hand Hibernate could significantly reduce development time, if developers know it and application is a goot fit (CRUD, filters).

My advice is to avoid ORMs unless your project is big and its database schema is a good fit. And if it is, don't think, that ORM is easy, it's not. Learn how it works, read its source code, understand its inner workings. Or find someone who does.

I didn't have much experience with other ORMs, though.

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

#258

Post by insulanian » Mon, Jun 27, 2016, 1:00 PM UTC

eru wrote: post #171

manigandham wrote: post #135

Not this again. Why is this coming up at all in 2016? There isn't even a valid debate here. ORMs are a tool, that's it. The relational operations of SQL and the object-oriented (or functional) logic of your application code are usually very different and it's nice to have a mapper that lets you interact with your app's language while it takes cares of automatically mapping it to SQL. For 99% of database ops where it'…

> ORMs are a tool, that's it. The relational operations of SQL and the object-oriented (or functional) logic of your application code are usually very different and it's nice to have a mapper that lets you interact with your app's language while it takes cares of automatically mapping it to SQL. Functional and relational models work really well together. At Standard Chartered we even went so far as to add relations a…

Could you provide some examples?

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

#259

Post by GrumpyNl » Mon, Jun 27, 2016, 1:01 PM UTC

MustardTiger wrote: post #256

StevePerkins wrote: post #34

Ten years ago, there was a blog post every other week bemoaning ORM's. Ten years ago, those posts often had merit. In 2016, this sentiment is outdated. A few points: 1. If you think that using an ORM means you don't have to learn SQL, then you're going to have a bad time. This is where most of the bad press originates... from people who never really learned SQL or their chosen ORM. An ORM provides type checking at yo…

>If you're not using an ORM, then you ultimately end up writing one. And doing a far worse job than the people who focus on that for a living. I don't understand why people keep repeating this myth. I do not use an ORM. I did not write one, or anything resembling one. I have absolutely no problems with accessing my database from my applications.

Same here and after heavily testing, the old school simple approach is much faster. ORM, you never know how many lines of code are involved.

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

#260

Post by GrumpyNl » Mon, Jun 27, 2016, 1:14 PM UTC

fishtoaster wrote: post #31

maxxxxx wrote: post #3

I think ORMs are a great tool to get something off the ground quickly. Like with most tools you will hit a point where they make things more difficult and then it's probably time to switch to SQL only or mix SQL with ORM especially for performance critical queries. In most applications I have seen the ORM provided a lot of value but there were cases where it needed to be augmented with raw SQL. I never understand why…

I completely agree. 90% of the queries in my app are no more complex than selecting from a table with a simple condition. I definitely find users = User.where(has_foo: true).limit(10) to be a lot more readable than rows = connection.exec_query("SELECT * FROM users WHERE has_foo=true LIMIT 10") users = rows.map { |row| User.build(row) } (And that's an example with no user-provided input) Likewise, any app of sufficien…

For me thats the opposite. I prefer "rows = connection.exec_query("SELECT * FROM users WHERE has_foo=true LIMIT 10")", because i can read and understand the query. By reaing it i can already tell if it is a good query etc. while "User.where(has_foo: true).limit(10)" tells me nothing.