[emmanuelay]

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.

[hackerfromthefu]

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.

[lcrz]

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.

[darkhorse13]

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.

[metafunctor]

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?

[BozeWolf]

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().

[darkhorse13]

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.

[sjwright]

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.

[darkhorse13]

I don't see why those things have to be mutually exclusive. You can understand your database and still use an ORM.

[metafunctor]

Yep. My point is that if you use an ORM, but don't understand your database, you're asking for trouble.

[ClikeX]

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.

[yxhuvud]

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.

[tylerhou]

When I found ActiveRecord insufficient, I found it easy to drop down to Arel for complex queries: https://www.rubydoc.info/gems/arel

[bdcravens]

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.

[WJW]

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.

[dragonwriter]

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

[bdcravens]

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.

[gregoriol]

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, ...).

[bhaak]

That's quite a broad statement. Can you explain how you come to that conclusion?