Received: from localhost (maia-5.hub.org [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id D03E89FA432 for ; Tue, 9 Jan 2007 11:13:45 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-new, port 10024) with ESMTP id 45354-01 for ; Tue, 9 Jan 2007 11:13:32 -0400 (AST) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.4 Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by postgresql.org (Postfix) with ESMTP id 8DEB79FA4B9 for ; Tue, 9 Jan 2007 11:13:37 -0400 (AST) Received: by ug-out-1314.google.com with SMTP id k3so3162818ugf for ; Tue, 09 Jan 2007 07:13:36 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=a4IEvFZgWJmhqmXZ7t6rhxmb+RxEhD7xTrAkBlDatJetAQwZqGeo2zTrWIdhd6rAkJ3PCixfy15Tywl8GykkbCBrxq4GbxahF3CikIAo/lZd3hCdLZVJCB9xqpYjbF22clNAZTjJfvNBrm0k5U/elIK1S79PDXj3hwax4prE1UE= Received: by 10.78.204.20 with SMTP id b20mr7945837hug.1168355615830; Tue, 09 Jan 2007 07:13:35 -0800 (PST) Received: by 10.78.57.4 with HTTP; Tue, 9 Jan 2007 07:13:35 -0800 (PST) Message-ID: Date: Tue, 9 Jan 2007 09:13:35 -0600 From: "Aaron Bono" To: "D'Arcy J.M. Cain" Subject: Re: Table relationships Cc: "Curtis Scheer" , pgsql-sql@postgresql.org In-Reply-To: <20070109094113.064bae02.darcy@druid.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_65659_13729957.1168355615675" References: <031936836C46D611BB1B00508BE7345D04DC1BB5@gatekeeper.daycos.com> <20070109094113.064bae02.darcy@druid.net> X-Google-Sender-Auth: 9d093b962f64b47d X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200701/20 X-Sequence-Number: 27172 ------=_Part_65659_13729957.1168355615675 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 1/9/07, D'Arcy J.M. Cain wrote: > > On Mon, 8 Jan 2007 17:07:56 -0600 > Curtis Scheer 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 This approach implies that the address defines the relationship between a company and the detail (the other departments/offices). I cannot think of a business model that would use this though there probably are some... Another alternative is to add another table which just holds the > address: > > company <===> department <===> detail > ^ ^ > | | > \==> address <==/ I'm not sure what this relationship is for. It would appear that a department can have different addresses for different companies. There are many possibilities. Which one is best will depend on > analysing your particular business model. > I agree whole heartedly. That is why I recommend starting with a logic structure before moving on to the physical. -- ================================================================== Aaron Bono Aranya Software Technologies, Inc. http://www.aranya.com http://codeelixir.com ================================================================== ------=_Part_65659_13729957.1168355615675 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 1/9/07, D'Arcy J.M. Cain <darcy@druid.net> wrote:
On Mon, 8 Jan 2007 17:07:56 -0600
Curtis Scheer <Curtis@DAYCOS.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

This approach implies that the address defines the relationship between a company and the detail (the other departments/offices).  I cannot think of a business model that would use this though there probably are some...

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

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

I'm not sure what this relationship is for.  It would appear that a department can have different addresses for different companies.

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

I agree whole heartedly.  That is why I recommend starting with a logic structure before moving on to the physical.

--
==================================================================
   Aaron Bono
   Aranya Software Technologies, Inc.
   http://www.aranya.com
   http://codeelixir.com
================================================================== ------=_Part_65659_13729957.1168355615675--