Re: Table relationships

From: "D'Arcy J(dot)M(dot) Cain" <darcy(at)druid(dot)net>
To: Curtis Scheer <Curtis(at)DAYCOS(dot)com>
Cc: pgsql-sql(at)postgresql(dot)org, postgresql(at)aranya(dot)com
Subject: Re: Table relationships
Date: 2007-01-09 14:41:13
Message-ID: 20070109094113.064bae02.darcy@druid.net
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-sql

On Mon, 8 Jan 2007 17:07:56 -0600
Curtis Scheer <Curtis(at)DAYCOS(dot)com> wrote:
> -> Is there a difference between an address for the customer detail and an
> address for the customer?
>
> Not really an address is an address, it's a matter of specify an address for
> the customer master record which basically represents an entire customer
> while the customerdetail represents departments within that company that
> might be at a different address then the company's main office for instance.

Could be that you need another table. Sounds like you have something
like;

company <===> address <===> detail

Now you just have to indicate which address is the primary or head
office. You can do that with a bool in the address table. You can
even add a unique, partial index to address to assure that you only
have one head office per company.

Another alternative is to add another table which just holds the
address:

company <===> department <===> detail
^ ^
| |
\==> address <==/

Obviously the address attached to the company is the head office. For
departments you can either duplicate the reference to the address table
or have NULL indicate a default to the head office.

There are many possibilities. Which one is best will depend on
analysing your particular business model.

--
D'Arcy J.M. Cain <darcy(at)druid(dot)net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.

In response to

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message Aaron Bono 2007-01-09 15:13:35 Re: Table relationships
Previous Message Curtis Scheer 2007-01-08 23:07:56 Re: Table relationships