I do not agree and this is coming from someone that loves SQL. I only experienced the problems that this article describes with people that do not know how the ORM works.
You can use an ORM and it works flawless for most cases. There might be some cases where I need to write SQL to generate a custom function or some weird edge case but that is why the ORM gives you the possibility to write your own SQL if you want.
I forgot to mention that having to write raw SQL queries and mantain them, doing migrations and keeping up with the changes is kind of a pain when most of the time the ORM takes care of everything.
ORMs are good for quickly building something. But if you're building something that is expected to last and that will be passed on to other developers... ORMs will likely derail or put severe limitations on your application.
Disagree completely. It depends, very much, on context.
There's contexts where good knowledge of the ORM, and of SQL, is part of the bar of working in the environment. This often happens in stacks where there aren't a zillion different choices but rather curated default choices for things like ORMS.
Combined with having a large and sophisticated system (or many similar small ones), then the complexity saving of being able to use a good ORM (and LINQ) provides a significant savings in time, and complexity.
This helps the systems to last, and be passed on to other developers.
Counterpoint: a lot of ruby devs are very familiar and capable with ActiveRecord. Al lot of python devs are familiar and capable with using the Django ORM. Why are these ORM more likely to limit your application? You provide no proof or explanation of your statement.
I second this. For example, Django's ORM is actually very advanced these days, allowing you to squeeze out the performance in many, many cases. While I agree that ORMs should not always be used (sometimes you just need raw SQL, especially on very large databases), I think the ORM hate is a bit overstated on HN.
The Django ORM is pretty good, and I like it. But, to squeeze out performance, wouldn't you say you have to actually understand what is going on in the database?
Agree! I like django's ORM and I love SQL databases. It is nice that your in-code model changes, will reflect the schema changes in the database. And migrations are a blessing. (Of course it has some foot guns.)
For optimizations:
my_queryset.explain(verbose=True, analyze=True) is very nice to understand what is going on. If you cannot get it done with django's database abstractions, there is always:
my_queryset.extra() or even my_model.objects.raw(). Where the last one maps the result to the model, for free.
To others responding that ORMs are bad:
IMHO saying that raw sql is better than ORMs is short sighted. Many simple things are nice in ORMs. Queries are often simple. Today, in django, complex queries are also nice. For edge cases raw sql can be better.
Extending queries is also super easy with a good ORM, where with raw sql you would have to maintain two almost the same queries.
Just remember to run and inspect queryset.explain().
Fully agree with this. These discussions are always this or the other, but you can easily have both in the same project. Django's ORM and raw SQL functions prove that.
And more importantly, you'd want to design your database to be optimal for complex SQL queries and not whatever generic structure that matches your programming objects.
The only limiting thing I've experienced with ActiveRecord is when the database becomes larger and more complex. The performance takes a bit of a hit. Which isn't ActiveRecords fault, it's the developer's lack of understanding how the database works.
Most of the issues I see is a lack of understanding of things like N+1 queries. I see this mistakes from junior to senior level. ActiveRecord has built in solutions to fix them too. Some developers don't know about them.
There are built-in solutions but also quite severe limitations when you get to advanced usage of activerecord. Especially with regards to composability. Of course, raw SQL is also really bad in that scenario.
Working on a Ruby application that uses a database that predates the application (it was originally written in another language), there are simply some things that can't be written in AR, or when they are, the performance just isn't there.
Additionally, we often have to create ad-hoc queries to answer questions from stakeholder. It's easy enough to just pop up DataGrip and write the query, and copy the tabular results into a doc in Google Sheets for sharing.
I think the best approach is ORM-first, not ORM-only.
An alternative viewpoint on that situation might be that the database is in need of some serious refactoring/migrating if the app can't deal with its structure. Trying to bend Rails into non-AR database usage is going to lead to tears sooner rather than later IMO. It's just so very integrated.
Having separate applications with (write) access to the same database is similarly going to end in trouble. Suddenly there are all sorts of problems when the database needs a migration and the applications are expecting different things from the same table. This is not really ORM-related btw.
That said, ActiveRecord is not perfect and sometimes a single handcoded SQL query can deliver a ton of value. Profile carefully.
> Trying to bend Rails into non-AR database usage is going to lead to tears sooner rather than later IMO. It's just so very integrated.
Is that really true? While I've barely used Rails in anger, and not at all recently, I was under the impression that all the major Ruby ORMs and high-level database libraries (e.g., DataMapper, Sequel) are heavily focussed on Rails usage and usually around AR pain points like working with DBs in Rails that don't fit ARs opinionated patterns.
> Having separate applications with (write) access to the same database is similarly going to end in trouble.
It shouldn't, if the DB is designed for that, which usually means each application sees the DB exclusively through its own set (probably in a distinct schema) of views, and keeps it's filthy little hands off base tables. That's a best practice for multiple application access to an RDBMS that is older than the Web.
I won't argue that an ideal situation is to stop all feature development and refactor into an ideal data model. That's a technical debt ROI discussion, the kind that we always have, and sometimes the business value just doesn't support the rewrite.
However, even in an ideal data model, I don't always agree that multiple applications accessing the application's database is bad. That's a matter of being thoughtful and communicative, instead of just wantonly running "rails g migration" every time you need to implement a feature (that's true of Monorails even). FWIW, we've never had any real issues with multiple applications accessing our single database.
The ORM actually might reduce the risk of derailing over time as it will probably handle any database layer upgrade, will perform checks to prevent common issues, while your own SQL might not (thinking of utf8/utf8mb4 on mysql8, newly reserved words escaping, special characters escaping, ...).
Our views on this tend to be influenced by the sorts of data applications we've written in the past. I can imagine that people who've done a lot of corporate/enterprise development with large teams or straightforward requirements would see immense value in an ORM. I'm sure that doesn't even begin to describe the breadth of projects where an ORM is a good idea. I've never built applications in this space so I can't speak to it.
With most of the stuff I do, an ORM is a non-starter for my databases. The data would make no sense as objects and I tend to avoid using data objects in programming anyway. It's probably impractical or impossible to build what I build using one and even if you could it would be more difficult to write and performance would certainly be atrocious.
You can use an ORM and it works flawless for most cases. There might be some cases where I need to write SQL to generate a custom function or some weird edge case but that is why the ORM gives you the possibility to write your own SQL if you want.
I forgot to mention that having to write raw SQL queries and mantain them, doing migrations and keeping up with the changes is kind of a pain when most of the time the ORM takes care of everything.