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

241–250 of 305 posts

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

#241

Post by lmm »

zepolen wrote: post #37
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…

Here's the thing, anyone who knows SQL will find the second one readable, and only Ruby programmers who have used ActiveRecord will know how the first one does.

What's your concern here?

Readability by maintenance programmers? How many Rails programmers will not know ActiveRecord? How many are going to be better at maintaining SQL than they are at maintaining ActiveRecord queries?

Readability by business people who don't know any programming languages? The first is a lot clearer than the second IMO.

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

#242

Post by sangnoir »

toast0 wrote: post #121
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…

> 2. 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. It's no different from people who "don't need a web framework", and then go on to re-implement half of Rails or Spring (without accounting for any CSRF protection). Learning any framework at a professional level is a serious time investment, and many student beginners or q…

> It's way less effort to just output some HTML, or just make a database query, than to learn a framework or ORM, and as a bonus it's usually faster too. Also, it's a lot easier to fix slow queries when there's one place that has the whole query (with placeholders where possible -- I may be crazy, but I'm not insane).

Do you work in a team? Or do you plan to hand over that code to someone else for maintenance at some point in time? If not, then by all means, go ahead. Another advantage of ORM/web frameworks is that they are properly documented and only have to be learned once. I once had the displeasure of maintaining someone elses custom 'framework' with no documentation.

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

#244

Post by lukaseder »

_pmf_ wrote: post #238
gregopet wrote: post #42

I've come to love jOOQ, the Java library that I can write type-safe pure SQL in (and with code that is immediately understandable to anyone who knows SQL). It provides mechanisms to smooth the clash of Java/SQL worlds, but otherwise never assumes it is smarter than the wisdom accumulated through decades of database usage. I've come to appreciate many aspects of databases again that tools like Hibernate try to hide fr…

I was intrigued by jOOQ, but the huge amount of generated code for internal metadata of the DB was a bit offputting. I don't want 4MB of generated classes for 3 very small tables.

Use the code generator's or flag or other means and you'll only get those 3 small tables generated...

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

#245

Post by oliwarner »

collyw wrote: post #54
oliwarner wrote: post #38

What reading articles on how bad ORMs are has taught me: More people need to use Django. Django does a lot and does it well.

I wouldn't say the ORM is Djangos strongest point. Its great for simple stuff, but not great for any moderately complex queries (e.g. extra conditions on a join, subqueries, conditional aggregates - though I think that last one may be solved in the most recent version). I don't think they have done a bad job with the ORM, but you really ought to know SQL as well.

I'm not arguing that people shouldn't learn SQL, I'm just saying that a lot of people who bemoan all ORMs should try using a really good one —like Django's— and see if all their complaints still ring true. Your examples, for example, might have been true a while ago but:

- Extra conditions on a join (eg a prefetch filter): https://docs.djangoproject.com/en/1.9/ref/models/querysets/#...

- I'm not sure what you think you'd want explicit subqueries for, at least in a context that annotations, prefetch, etc don't already do. If it's that weird, just use `.extra(..)`

- Conditional aggregates: https://docs.djangoproject.com/en/1.9/ref/models/conditional...

- Not that you asked but also have a look at the new database functions stuff. http://stackoverflow.com/questions/38017076/annotate-a-comma...

And it keeps getting better. The list of "ORMs are rubbish because I can't do X" is evaporating. Yeah there's probably some stuff that never comes up but you can still run raw SQL through the ORM.

When you consider the development time saved and performance improvements (caching, good query writing, etc) an ORM delivers, I personally think it's hard to argue against them.

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

#246

Post by codersteve »

BurningFrog wrote: post #134
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…

One problem with the stored procedure approach is that it scales terribly. If your logic is in app servers and your state in a DB, you can add more app servers, and it will be a long time until your DB get overwhelmed. When your DB is doing both , the choking point is much earlier.

Many applications don't need Facebook/Twitter scale and will never have this problem.

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

#247

Post by eru »

pbowyer wrote: post #200
eru wrote: post #171

Earlier quoted context omitted.

> 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…

> At Standard Chartered we even went so far as to add relations as a datatype to our Haskell-like language. It's a charm; and comparable for me to my experience first going from C-style arrays only to eg Python's dicts. Have you written about this? It sounds really interesting.

I haven't written about this yet, alas. There's a bit of information at https://www.reddit.com/r/haskell/comments/2u0380/slides_from...

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

#248

Post by platz »

brightball wrote: post #181
platz wrote: post #105

Earlier quoted context omitted.

Zero downtime deployment with stored procedures should not be confused with "version control". It's not a version control scheme; once deployed the procs are never updated.

Yea, I suppose backwards compatibility is really the best policy there. If a proc is going to be updated to be more efficient it's one thing. If it's going to change what it does then we just need a new proc.

Yep. (if there are schema, changes too, zero downtime & backward compatability is difficult to pull off, but thats a chore for any strategy )

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

#249

Post by spacecowboy_lon »

Udik wrote: post #224
spacecowboy_lon wrote: post #208

Earlier quoted context omitted.

That is normally considered a good thing other wise different applications accessing the same data have to roll there own - do you really want multiple versions of biz logic. eg a large organizations like a bit telco may have multiple applications that update customer records.

Should they do that through a single service api instead of directly hitting the database?

Midleware is the normal term

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

#250

Post by zamalek »

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

> A lot of things people use ORMs for are rather easily solved with stored procedures More like 1 thing. ORMs are meant to make interfacing through the object/relational impedance mismatch easier and through the regular code in your application. Stored procedures do not come anywhere close to this and are usually the same as just calling any other SQL query as you would when not using an ORM. If you think any majorit…

> you're not really using an ORM for much at all.

The ORM can do transient fault recovery (including other cloud patterns) as well as modernise the interface (Micro-ORMs in general).

Post reply on HN