SQL is a write-only language. You better hope you don't have to rewrite your complicated raw SQL queries in the future.
You can write well written modular SQL that supports changes and can be read by a competent developer.
What ORMs have taught me: just learn SQL (2014)
51–60 of 305 posts
Re: What ORMs have taught me: just learn SQL (2014)
#52Ten 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…
> An ORM provides type checking at your application layer
This. When composing complex queries, we really want type checking and SQL injection safety.
Re: What ORMs have taught me: just learn SQL (2014)
#53SQL is a write-only language. You better hope you don't have to rewrite your complicated raw SQL queries in the future.
You can write well written modular SQL that supports changes and can be read by a competent developer.
Not in my experience. Please show me actual examples of "well-written modular SQL" in a real application.
Re: What ORMs have taught me: just learn SQL (2014)
#54What 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.
Re: What ORMs have taught me: just learn SQL (2014)
#55I've always said: "ORMs are for people who don't know SQL!"
> I've always said: "ORMs are for people who don't know SQL!"
False. To use an ORM you must know and understand data modelling and the Entity/Relationship model. I'd say, people who don't like ORMs are often those who don't understand that model.
If you do understand it, then you know that relationships can be represented 100% by code in an OO language, thus completely automated.
Why bother writing your own hydrators for each entity when you can model them directly in a library? it doesn't make a codebase more maintainable or readable.
Furthermore you could have an ORM that uses SQL directly for queries, and still eagerly resolve relationships. It's just not practical, that's why ORMs often come query builders.
That is the thing that abstracts SQL, not an ORM per say. ORMs only deal with relationships between entities. Query Builders build SQL queries.
Re: What ORMs have taught me: just learn SQL (2014)
#56I'm curious how the author would like MyBatis, which is just a thin wrapper for calling SQL, and then translating results to POJOs. I like it, and it, IMO, keeps the API distinct from the access in the DB. You have to write your own SQL, which is good and bad. Huge amounts of control and performance, but higher portability costs.
Also Records for Python: https://github.com/kennethreitz/records
Re: What ORMs have taught me: just learn SQL (2014)
#57I, like many other people, also took a stab at my ORM / ActiveRecord lib (First for PHP on MySQL, later ported it to Javascript on WebSQL) and I've been following exactly the sentiment that a people here seem to have to: Don't make your ORM want to do everything. If you are going to need computed N+1 queries, write a View, or use custom SQL.
ORM / ActiveRecord is a great pattern imo, but if you want to make it do everything, like so many other techniques, you're gonna end up with a behemoth of a thing.
I've tried many different ORMs in the last couple of years, and while mine may not be the most complete or have a sexy API for joining custom query parameters into the results, I still feel my own provides the one and only syntax / workflow 'as it should be' in Javascript:
var serie = new Serie();
serie.name = 'Arrow';
serie.TVDB_ID = '257655';
serie.Persist().then(function(result) {
console.log("Serie persisted! ", result);
});
https://github.com/SchizoDuckie/CreateReadUpdateDelete.js
(browser that supports WebSQL required, obviously)
Re: What ORMs have taught me: just learn SQL (2014)
#58Earlier quoted context omitted.
But how do you do: SELECT posts.*, (SELECT COUNT(1) FROM comments WHERE post_id = posts.id) AS comments_count FROM posts; In ActiveRecord, without 1+N queries, or caching comments_count in a column somewhere? Admittedly, that was not the best example. The last time I need something more intertwined than a simple COUNT in subquery, the answer was "give up and just use Arel." But at this point it is no longer quite Act…
That's really easy. Post.select("posts.*, count(comments.*) as comments_count").joins(:comments)
Thanks for the answer!
Unfortunately, what I needed to do back then were more complex than that (say, I need to perform query on top of subquery, e.g. "SELECT ... FROM (SELECT ...) AS a HAVING ... GROUP BY ..." sort of thing) which seems to be something ActiveRecord wasn't designed for.
In the end, I solve the problem by using Arel with an ActiveModel and unwrap all the data manually.
Re: What ORMs have taught me: just learn SQL (2014)
#59As much as I advocate for properly using SQL, I still want an ORM (lightweight) to manage the repetitious small stuff that happens repeatedly throughout an application. I'm all about custom SQL or stored procedures when the time comes though.
Re: What ORMs have taught me: just learn SQL (2014)
#60Previous discussion:
https://news.ycombinator.com/item?id=8133835