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

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.




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

Search: