Hacker News new | past | comments | ask | show | jobs | submit login

I’m a Rails developer by trade, been doing it for over a decade. Bad indexing and lazy N+1 are 90% of the performance problems in a typical rails application. The other 10% is when people do aggregates or joins in application code instead of sql. I absolutely despise ActiveRecord because it makes non-trivial aggregates a pain to write. Sequel is a much better ORM but good luck getting a team on board.



    I absolutely despise ActiveRecord because it makes 
    non-trivial aggregates a pain to write
I'm a SQL guy at heart.

I certainly agree with you... I loathe writing any non-trivial query in ActiveRecord's query builder.

However, I find ActiveRecord does a really good job of getting out of the way when I deem it easier to write some raw SQL.

Generally do one of two things.

If I have a really big nasty query, I'll implement it as a (standard or materialized) database view. I may query it directly or map a model to it.

Or, I'll just use `MyModel.find_by_sql("blahblahblah")` which happily accepts my handwritten SQL.

I don't have a link handy but DHH stated ages ago that the ability to do stuff like that was an explicit goal of ActiveRecord.


I would like some kind of middle ground, which is why lately I tend to lean toward using something like Sequel and mapping my own domain entities. Mixing domain entities with persistance has proven to me to be a colossally bad idea.

I'm in the process of writing a rather large new feature for our application that heavily uses aggregates and window functions, and writing queries that try to use these sql feature while also taking advantage of scope chaining is just an exercise in pure frustration.

I think the more I lean on "advanced" SQL features, the more I just think I've probably outgrown Rails personally because it doesn't easily enable the kind of solutions that I need.


    why lately I tend to lean toward using something like 
    Sequel and mapping my own domain entities
I'm definitely itching to use something leaner like Sequel in a project. Before coming to Rails I used some nice lean C# ORMs like PetaPoco and Dapper and I really enjoyed that approach.

    I think the more I lean on "advanced" SQL features, 
    the more I just think I've probably outgrown Rails 
    personally because it doesn't easily enable the kind 
    of solutions that I need.
I definitely agree that the "treat the database as a dumb, interchangable storage solution" mentality that infects Rails and other development communities is misguided IMO. Leaning into more advanced database stuff quite frequently the way to go for non-trivial solutions.

In practice, I still find Rails pretty amenable to a data-first approach. Applications tend to be a mix of advanced database stuff and simple CRUD operations. Realistically, a lot of developers are good at one but not the other. So on a given team, a mix of developers is able to play to their strengths.


I think you just summarized the entire article in thee sentences. Thanks!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: