While not 100% Rails related I had a quick question while designing my app... Whats the best practice for contacts and addresses. I would assume a company has many addresses and contacts? How do some of you deal with this? In my case, I have many companies, each with different addresses (ship to and bill to) as well as different contacts at these addresses. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Hi ! 2007/1/8, Shai Shefer <shai.shefer@gmail.com>:> While not 100% Rails related I had a quick question while designing my > app... > > Whats the best practice for contacts and addresses. I would assume a > company has many addresses and contacts? How do some of you deal with > this? > > In my case, I have many companies, each with different addresses (ship > to and bill to) as well as different contacts at these addresses.Address should be a full-fledged model, with a polymorphic association to Company and/or Contact and/or Invoice. If you want to reuse addresses, you'll need a join model between contacts et. al and Address. As you said, this is really data modelling, and not Rails. But great discussion should ensue anyway ! Bye ! -- Franois Beausoleil http://blog.teksol.info/ http://piston.rubyforge.org/ --~--~---------~--~----~------------~-------~--~----~ 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@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
Maybe you shouldn''t be looking for best practice. It''s going to cost you big. You could, for example, stick to the sample data you have and put the 2 addresses directly in the company table. And then relate the contacts to this table. The problem here is if you get another branch of the same company. You''ll have to rename both branch in "Megacorp Shanghai" and "Megacorp NY" both entries being unrelated in your data model, and both containing a billing address that may be the same... It''s up to you, but take everything in consideration and go for the simplest your-industry-specific time-and-money-saving-model you can. Think about the way you are going to import and enter your existing data, too. It can be a real nightmare if you play it too "100%". --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Hi,
don''t have experience regarding this with Rails, but based on
experience with Siebel (a CRM package) you could go with something
like this (I don''t have much experience with Rails yet, so bear with
me):
You would have your three tables:
companies { |t|
t.column :bill_to_id
t.column :ship_to_id
# more columns
}
contacts { |t|
t.column :company_id
t.column :business_addr_id
# more columns
}
addresses { |t|
t.column :company_id
# more columns
}
Each address would belong to a company and you wouldn''t want to delete
addresses (maybe just a deleted flag or a status field). So a company
could have maybe just one, maybe two, maybe 16 addresses (old
addresses, different office locations, ...)
Only one of those addresses would be your bill to address and only one
would be the ship to address (in Siebel these are called something
like "Primary Ship To Address" and "Primary Bill To
Address"). To
select them you could pick one of the company''s addresses from a drop
down list. You could select the same address for both resulting in
company.bill_to_id == company.ship_to_id or it could be different
addresses.
There would be joins company.bill_to_id -> address.id and
company.ship_to_id -> address.id and a 1:many relationship from
company.id -> address.company_id
Now, each contact would be associated with a company. When you select
the contacts address, you again pick one of the company''s addresses
from a drop down list. (You might even have the HQ address in
company.addr_id and use that as a default for the contact)
There would be a join from contact.business_addr_id -> address.id
Orders could be handled similarly. They would belong to a company and
the default bill to and ship to addresses would be the primary ones of
the company (company.bill_to_id and company.ship_to_id). But you could
change those and pick another address from a drop down list of company
addresses and populate order.bill_to_id and order.ship_to_id
accordingly.
Let me know if you''ve got questions about this.
Thomas
2007/1/9, Benoit B.
<benoit.benezech-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:>
> Maybe you shouldn''t be looking for best practice. It''s
going to cost
> you big.
> You could, for example, stick to the sample data you have and put the 2
> addresses directly in the company table. And then relate the contacts
> to this table.
> The problem here is if you get another branch of the same company.
> You''ll have to rename both branch in "Megacorp Shanghai"
and "Megacorp
> NY" both entries being unrelated in your data model, and both
> containing a billing address that may be the same...
> It''s up to you, but take everything in consideration and go for
the
> simplest your-industry-specific time-and-money-saving-model you can.
>
> Think about the way you are going to import and enter your existing
> data, too. It can be a real nightmare if you play it too "100%".
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---