X-Original-To: pgsql-sql-postgresql.org@postgresql.org Received: from localhost (wm.hub.org [200.46.204.128]) by postgresql.org (Postfix) with ESMTP id 697C79F9316 for ; Wed, 2 Aug 2006 15:02:17 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024) with ESMTP id 89781-09 for ; Wed, 2 Aug 2006 18:02:01 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey- Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by postgresql.org (Postfix) with ESMTP id 440DC9FB22A for ; Wed, 2 Aug 2006 15:02:00 -0300 (ADT) Received: by nf-out-0910.google.com with SMTP id p77so747733nfc for ; Wed, 02 Aug 2006 11:01:57 -0700 (PDT) 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=G1gOc5lkgPyg3YCNTB5rvp9ki11k5bRwisfDKRuzvw+ziityJZoOz3Tz5m78Im6fpH6BCkNkFmF4UUV9EtW+cr8dTHl7vH0sbWPHJ3N3ABHuWdGe9J6hJOkn2UXEBByFegcFIWgH8KqTkSL9CpQkP9PnangERQPqEFmQg7NBXTY= Received: by 10.78.170.17 with SMTP id s17mr318944hue; Wed, 02 Aug 2006 11:01:57 -0700 (PDT) Received: by 10.78.32.10 with HTTP; Wed, 2 Aug 2006 11:01:57 -0700 (PDT) Message-ID: Date: Wed, 2 Aug 2006 13:01:57 -0500 From: "Aaron Bono" To: "John Tregea" Subject: Re: Joining a result set from four (4) tables Cc: pgsql-sql@postgresql.org In-Reply-To: <44D02242.5050309@debraneys.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_94316_11693211.1154541717397" References: <44CDB1EF.6000508@debraneys.com> <44CE9C63.7010409@debraneys.com> <44D02242.5050309@debraneys.com> X-Google-Sender-Auth: c13a32943d02a88b X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=3.817 tagged_above=0 required=5 tests=HTML_MESSAGE, SPF_HELO_SOFTFAIL, SPF_SOFTFAIL X-Spam-Level: *** X-Archive-Number: 200608/19 X-Sequence-Number: 25977 ------=_Part_94316_11693211.1154541717397 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 8/1/06, John Tregea wrote: > > > Because the logic structure of this software is in the front end > application rather than the database there is a strong need to keep the > naming of fields generic rather than specific, I am not using > pre-defined foreign keys at all. If I was building the database with a > purpose specific goal I would be doing what you say. I have found though > that when I label elements at different levels of the back end for one > purpose, they are less transportable in the long run. In this case the > naming conventions are actually stored in another table and applied as > aliases when needed. That way I can change the names and labels (for a > new client or industry) while the underlying structure remains the same. > I hope to increase interoperability in this way as well. We all find ourselves in different situations and because of that, what works for one person, doesn't work for another - so I understand. Good luck with the application and future queries. Maybe you can use the existing structure of your application to help create a query builder so you can have it write a lot of your joins for you. That should help avoid a lot of simply typos or mix-ups when hand writing your queries. I am glad the queries worked for you. -Aaron ================================================================== Aaron Bono Aranya Software Technologies, Inc. http://www.aranya.com ================================================================== ------=_Part_94316_11693211.1154541717397 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 8/1/06, John Tregea <john@debraneys.com> wrote:

Because the logic structure of this software is in the front end
application rather than the database there is a strong need to keep the
naming of fields generic rather than specific, I am not using
pre-defined foreign keys at all. If I was building the database with a
purpose specific goal I would be doing what you say. I have found though
that when I label elements at different levels of the back end for one
purpose, they are less transportable in the long run. In this case the
naming conventions are actually stored in another table and applied as
aliases when needed. That way I can change the names and labels (for a
new client or industry) while the underlying structure remains the same.
I hope to increase interoperability in this way as well.

 
We all find ourselves in different situations and because of that, what works for one person, doesn't work for another - so I understand.  Good luck with the application and future queries.  Maybe you can use the existing structure of your application to help create a query builder so you can have it write a lot of your joins for you.  That should help avoid a lot of simply typos or mix-ups when hand writing your queries.

I am glad the queries worked for you.

-Aaron

==================================================================
   Aaron Bono
   Aranya Software Technologies, Inc.
   http://www.aranya.com
================================================================== ------=_Part_94316_11693211.1154541717397--