3 ms·

I don't understand why the author first describes how bad N+1 queries are and then later claims that they are sometimes good? Yes, of course that can be true in

I don't understand why the author first describes how bad N+1 queries are and then later claims that they are sometimes good? Yes, of course that can be true in very specific circumstances, but in many cases I've seen atrocious performance due to N+1 queries and fixing them was the first step in making an unresponsive website perform. Don't also really agree that adding validations, joins etc. to your DB is "coupling your application logic to the DB" or that it makes the app slower (???). The thing that is coupling your business logic to the DB is a bad architecture which, unfortunately, most ORMs (including ActiveRecord) encourage. The fact that you can access a propery on an ActiveRecord object in a view and have this secretly make a database call, is one of the reasons for those infamous N+1s.

brightball 4y ago
The thing about Ruby is there are plenty of gems that will help protect your code base from many of the performance hiccups. Off the cuff: bullet, strong_migrations, activerecord-import, lol_dba I'm sure there are more. This has been a bit of a passion point for me for a few years. I even taught a class on it. Ruby is a wonderful language to use with a database. ActiveRecord too...you just have to know how to avoid some of the foot guns. Many Rails devs get committed to doing things "the Rails way" to ship faster and focus on application level logic, but even the ActiveRecord guides say that when it's time to performance tune you're going to have to get into the database innards. ActiveRecord is geared towards team productivity. It's perfectly capable of great efficiency too, you just have to be more deliberate about it. The "scopes" structure is wonderful for piecing together reusable parts of queries though. It makes leveraging the fancy parts much easier.
- Tainnor 4y ago
  Libraries are great, but they're not a fix for a broken architecture. It's been quite a while that I haven't worked with in Ruby on Rails, but the fact that "architecture" was often considered a dirty word and the "Rails way" was touted as the solution to all problems in my experience often led to systems where everything was coupled to everything. > ActiveRecord is geared towards team productivity. ActiveRecord is geared towards making things easy at the start. The problem is that every ActiveRecord object always carries a dependency to the DB around, making it difficult to enforce a clean separation between different layers of your system.

brightball 4y ago

The thing about Ruby is there are plenty of gems that will help protect your code base from many of the performance hiccups. Off the cuff: bullet, strong_migrations, activerecord-import, lol_dba I'm sure there are more. This has been a bit of a passion point for me for a few years. I even taught a class on it. Ruby is a wonderful language to use with a database. ActiveRecord too...you just have to know how to avoid some of the foot guns. Many Rails devs get committed to doing things "the Rails way" to ship faster and focus on application level logic, but even the ActiveRecord guides say that when it's time to performance tune you're going to have to get into the database innards. ActiveRecord is geared towards team productivity. It's perfectly capable of great efficiency too, you just have to be more deliberate about it. The "scopes" structure is wonderful for piecing together reusable parts of queries though. It makes leveraging the fancy parts much easier.

Tainnor 4y ago
Libraries are great, but they're not a fix for a broken architecture. It's been quite a while that I haven't worked with in Ruby on Rails, but the fact that "architecture" was often considered a dirty word and the "Rails way" was touted as the solution to all problems in my experience often led to systems where everything was coupled to everything. > ActiveRecord is geared towards team productivity. ActiveRecord is geared towards making things easy at the start. The problem is that every ActiveRecord object always carries a dependency to the DB around, making it difficult to enforce a clean separation between different layers of your system.