Using Associations vs Child_Model.find

I have a model (Parent) that has a has_many association with another model (Child). I read that there are performance issues (relating to GC) with too many associations. I was about to add more has_many associations to the parent model to get child objects ordered by different columns like so:

(Inside Parent model) ...   has_many :child, :through => :childx, :order => "category_1, date_1 desc"   has_many :child1, :through => :childx, :source => :child, :order => "updated_at desc"   has_many :child2, :through => :childx, :source => :child, :order => "date_1 desc"   has_many :child3, :through => :childx, :source => :child, :order => "name_1" ...

Is this going to make ruby hold on to this parent object and 4 child object and use up a lot of memory? (Does the parent model get all the child records child, child1, child2 and child3 as soon as Parent.find is called? Or are they only really queried when I access, say, parent.child1?)

Is it better to just do a Child.find with the parent_id inside the controller? Or would it use up as much memory as soon as I do Child.find?

Thanks for any insights!

khagimoto wrote:

I have a model (Parent) that has a has_many association with another model (Child). I read that there are performance issues (relating to GC) with too many associations. I was about to add more has_many associations to the parent model to get child objects ordered by different columns like so:

(Inside Parent model) ...   has_many :child, :through => :childx, :order => "category_1, date_1 desc"   has_many :child1, :through => :childx, :source => :child, :order => "updated_at desc"   has_many :child2, :through => :childx, :source => :child, :order => "date_1 desc"   has_many :child3, :through => :childx, :source => :child, :order => "name_1" ...

This design cries out for refactoring... as soon as I see something1, something2, something3 when the series is essentially infinite (though I wouldn't want to feed or clothe them all), alarm bells start ringing.

Consider a 'relations' model that takes a person id, a different person id, and a relation (child, parent, grandparent, spouse, ex-spouse, etc, etc), which maintains that "person1 is a relation of person2".

Extra points if you implement the relation model in a bi-directional order (each relation needs to know its inverse), whereby creating the tuple 'person1, parent, person2' automatically creates 'person2, child, person1'.

Thanks, Ar Chron - I'm afraid I don't really understand what you're suggesting that I do. (sorry..) I already have a cross-reference table (childx) between the parent and the child that connects them. In my model, parent has many child, but child can have only one parent.

The only reason I am defining the child, child1, child2 and child3 inside the parent model is to get a list of child records that belongs to a parent sorted by different columns in the child table. (I thought it was an easy and efficient way to get at the record .. :-\ but maybe this is not a good idea?) And my question was if this is better or worse memory-wise than doing something like this:

             # method defined in the Child model             Child.find_by_parent_id(some_parent_id, sort_order)

inside the controller each time I needed a child record pulled sorted by a different column. (So no child, child1, child2 or child3 defined in Parent.)

Thanks again - I'll try to read more to understand this. Maybe it'll lead to what you were trying to tell me in the first place. :slight_smile:

I have a model (Parent) that has a has_many association with another model (Child). I read that there are performance issues (relating to GC) with too many associations. I was about to add more has_many associations to the parent model to get child objects ordered by different columns like so:

(Inside Parent model) ... has_many :child, :through => :childx, :order => "category_1, date_1 desc" has_many :child1, :through => :childx, :source => :child, :order => "updated_at desc" has_many :child2, :through => :childx, :source => :child, :order => "date_1 desc" has_many :child3, :through => :childx, :source => :child, :order => "name_1" ...

Is this going to make ruby hold on to this parent object and 4 child object and use up a lot of memory? (Does the parent model get all the child records child, child1, child2 and child3 as soon as Parent.find is called? Or are they only really queried when I access, say, parent.child1?)

Is it better to just do a Child.find with the parent_id inside the controller? Or would it use up as much memory as soon as I do Child.find?

Provide some named scopes in Child to do the sorting then you can do parent.children.sorted_by_desc parent.children.sorted_by_name or whatever (you might think of better names). This should do the sort in the db query so there should be no efficiency issues, provided you have indexes on the sorted columns of course.

Colin

Hi Colin, This was exactly what I was after. I have to do some performance testing, but it already seems faster with named_scope. :slight_smile: Thanks very much! Kumi