From: Daniel N <has.sox@...>
Date: 2006-09-28T16:43:09+09:00
Subject: Re: Ruby on Rails Relationships

------=_Part_10634_4545669.1159429386182
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 9/28/06, Murdoc <murdoc_0@hotmail.com> wrote:
>
> Innocent wrote:
>
> > > Then rails is expecting the venue_id field to be present in the
> > > address table. It seems illogical to setup the relationship with the
> > > "belongs_to :address" tag in the Venue model, as a Venue does not
> > > belong to an address, it has an address.
> >
> > I think you're mixing the object model with the DB schema.  Yes--in
> > object modeling, if a venue has an address, you'd expect the Venue class
> > to have a pointer to an Address.  However, in relational DB schemas,
> > it's the child table (address) that should have a foreign key
> > to the parent table (venue)'s primary key.
> >
> > This becomes more clear if you think about how to represent one-to-many
> > relationships.  Remember, a column in a table should contain only one
> value.
> > You may have many rows in a table, but each column in a row should
> > have only one value.
>
> First, it isn't a one-to-many relationship. Each venue can only ever be
> associated to a single address record. However, that address may be shared
> amongst multiple entities (each of which can only ever be linked to one
> address).
>
> I would have thought that this would be a common scenario that shouldn't
> be that hard to model in Rails.


Is this correct then?
class Address < ActiveRecord::Base
  has_many :entities
end

class Entity < ActiveRecord::Base
  belongs_to :address
end

Sounds like a one to many to me...
The address id then goes as a foreign key into the Entity table
address_id INTEGER

Hope I've understood you correctly...

------=_Part_10634_4545669.1159429386182--