I'm quite new to rails. These may be silly questions, but I really
need your advice.
According to <<Agile Web Development with Rails>>, composite objects
in aggregation are value objects, which means their values cannot be
changed. So if say Person is the model class and Address is the
composite class, the way to update a person's address is to create a
new Address object, assign it to the person and then save. This works
fine with small composite object with just a few properties. If the
composite object has many properties, I think this will a performance
problem.
Now in my project, I get a table with about 50-60 columns. I want to
divide it into several parts using aggregation. The problem is that,
one of these composite objects will have 20 columns and another with
10 columns. I'm wondering if this will cause a performance problem
since each time even only one of the composite object's properties
needs to be updated, the whole 20 columns or so will be updated
together. Is there a way to avoid this? Or this is just the way rails
work?
I was thinking about split this big table into several small ones, but
this doesn't seem to be reasonable in a OO perspective. Do I have to
split the table in order to hold performance or is there better way?
Aonther question is about multi-layer aggregation, say I want to model
a table into A, B, C there classes and use a a.b.c relationship. Is
this possible?
I’m quite new to rails. These may be silly questions, but I really
need your advice.
Not silly. Just inexperienced.
According to <>, composite objects
in aggregation are value objects, which means their values cannot be
changed. So if say Person is the model class and Address is the
composite class, the way to update a person’s address is to create a
new Address object, assign it to the person and then save.
Not the case, in actuality.
You can do
person.address.zipcode
= ‘63201’
person.address.save
or (since you said aggregation),
address1 = person.addresses[0]
address1.zipcode = ‘63201’
address1.save
This works
fine with small composite object with just a few properties. If the
composite object has many properties, I think this will a performance
problem.
Now in my project, I get a table with about 50-60 columns. I want to
divide it into several parts using aggregation. The problem is that,
one of these composite objects will have 20 columns and another with
10 columns. I’m wondering if this will cause a performance problem
since each time even only one of the composite object’s properties
needs to be updated, the whole 20 columns or so will be updated
together. Is there a way to avoid this? Or this is just the way rails
work?
If you only need to update one column, you can use lines such as:
person.address.update_attribute(“zipcode”, “63102”)
I was thinking about split this big table into several small ones, but
this doesn’t seem to be reasonable in a OO perspective. Do I have to
split the table in order to hold performance or is there better way?
Aonther question is about multi-layer aggregation, say I want to model
a table into A, B, C there classes and use a a.b.c relationship. Is
this possible?
Absolutely, as the other poster said. It is a standard practice in Rails.
Thanks for your patient explanation. Where can I get a close look to
all this rails API besides the online document on the offical web
site. Is there a downlaodable version? Since I cannot stay online all
the time.
Another question: Say I want to create a composite class with 20
properties, must I create the initialize method using all these
properties? This is boring and easy-mistaken. Is there a better way to
do this?
If you only need to update one column, you can use lines such as:
person.address.update_attribute("zipcode", "63102")
just want to clear this up. update_attribute() does not just update a
single column in the database. it updates the single attribute in the
model then saves the record..
