Rails - Jan 2009 - Modeling complex associations

Hi,

Is there any default way to model something like the following
situation in ActiveRecord?:

A company has_many :buildings which are associated to :company, e.g.
in a polymorphic way.
Moreover one and only one of the buildings is the company''s
headquarter.

Thinking in terms of the database, I''d prefer to add an owning
association, an thus have a has_many :buildings plus a
has_one :headquarter, :class => "Building" assocation, where the
foreign key "head_quarter_id" should be assigned to the company and
refer to the buildings table.
I''d prefer that to tagging one building with a headquarter-flag
because there''s the advantage of only being forced to change one
dataset (the company, more exactly its headquarter_id), instead of
changing two flags.

Is there any way to map that to ActiveRecord?

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

be careful: you''re building a ring. that''s a complex and so
trivial
thing.

obvious problem: for a company to store the foreign key of its
headquarter the building has to exist. for that building to store the
foreign key of the company that it belongs to, the company has to
exist.

to simplify it, there are a couple of solutions:
- you could just use an additional attribute in building
"is_headquarter" (bool) <-- your mentioned headquarter flag
- you could add an additional model headquarter that has many
branches, such that "a company has_one headquarter" and "it
has_many
branches through headquarter".  <-- problem here: hard to upgrade a
branch to headquarter and data-redundancy
- you could create a polymorphic building with an interface for
headquarter and branch
http://wiki.rubyonrails.org/rails/pages/UnderstandingPolymorphicAssociations

imho the last option seems to be the best.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Thanks very much for the hint - I didn''t think of that problem.
> - you could create a polymorphic building with an interface for
> headquarter and branch
I think it''s a good idea to differentiate headquarters and building
using another model (did I get this right?)
Would you suggest - assuming that building belongs_to company in a
polymorphic way - to create a table for headquarters? As it''s just a
unique property among the set of buildings belonging to one company
maybe it''s good to use STI and let Headquarter inherit from Building.
In the database this would result in a kind of flag (the type column)
as well, but maybe it would cause more readable code and prevent some
"if building.headquarter" patterns.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

> I think it''s a good idea to differentiate headquarters and
building
> using another model (did I get this right?)
That depends... is there something substantively different about a 
building that is designated as the headquarters? I.e., are you 
maintaining additional data that is specific to a "headquarters"?

If I think about bigger office buildings, there can be several companies 
that lease individual floors of a building (sometimes sections within 
floors). Any of those areas might be the individual company''s 
headquarters, while it''s all the same physical building.

So if companies can have space in multiple buildings, and a single 
building can house space for multiple companies, you need a join table 
that represents company-building combinations (officespaces?), and it 
seems that this join entity is what you would need to designate as a 
headquarters or not.
-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

I agree with Ar that you simply need a join table to hold the
relationship from the Company to its Headquarters instead of using an
object hierarchy and inheritance. Using Modules to insert and

class Company
  company_id
end

class Building
  building_id
end

class CompanyHeadquarters
  company_id
  building_id
end

Having the CompanyHeadquarters object may come in handy if you need
extra information about the Headquarters building that is different
from a normal building.

On Jan 19, 9:44 am, Ar Chron
<rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:
> > I think it''s a good idea to differentiate headquarters and
building
> > using another model (did I get this right?)
> That depends... is there something substantively different about a
> building that is designated as the headquarters? I.e., are you
> maintaining additional data that is specific to a "headquarters"?
>
> So if companies can have space in multiple buildings, and a single
> building can house space for multiple companies, you need a join table
> that represents company-building combinations (officespaces?), and it
> seems that this join entity is what you would need to designate as a
> headquarters or not.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Ok, thanks!

Maybe it''s also easier to reflect the situation that a company moves
its headquarter from one building to another. Then there''s only the
join table which is affected.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---