开发者

Rails Minimizing Database Load

开发者 https://www.devze.com 2023-04-01 19:26 出处:网络
I am relatively new to rails. I understand that rails lets you play with your database values with much ease but I am a little bit in the blind about what kind of approach is more energy efficient on

I am relatively new to rails. I understand that rails lets you play with your database values with much ease but I am a little bit in the blind about what kind of approach is more energy efficient on the database and whic开发者_C百科h not.

Here is a case in point. I have a model appointment which belongs_to user. In my syntax I can sometimes say process_user @appointment.user. When I write that, does that run a separate SELECT query on the database to retrieve that user? Is it more efficient to write process_user @appointment.user_id where user_id is an attribute in the appointment and then try use the user_id value to perform my evaluation related tasks as long as I don't need the whole user object @appointment.user.

Frankly, from a peace of mind point of view, I just love to be able to use process_user @appointment.user because it reads better, looks nicer and works better when preparing logic. Is it a performance efficient way?


You are perfectly fine with using code like process_user @appointment.user, as ActiveRecord tries its best to minimize the number of database queries. Of course it does not handle all situations perfectly, but your example is a very basic one. There would probably no immediate database query happen and the object would only be loaded when its attributes are accessed.

If you notice performance problems in a running large-scaled application and you can track the problems down to ActiveRecord using profiling, it is probably time to optimize. Trying to pre-optimize from the very beginning would be against Rails' philosophy and will only result in ugly (and possible even slower) code. Remember that the real performance bottlenecks are often at places where you would never expect them.

EDIT: As Winfield pointed out, optimizing the number of queries does usually not mean to manage foreign keys or similar internals by yourself. There are quite a number of flags and options for DB access methods that allow you to control how your database is queries.


You can eagerly load your associated users with your Appointment models:

Appointment.all(:include => :user)

...which will join in the users or do a separate lookup for all the associated users in a single query.

This will then load the user association in advance (eagerly) so the user attribute is already populated with the object when you reference it, instead of having to stop and execute a separate query to look it up one by one (N+1 queries).

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号