From: John Gunther <postgresql@bucksvsbytes.com>
To: pgsql-sql@postgresql.org
Subject: Re: joining a table whose name is stored in the primary record
Date: Tue, 19 Jun 2007 14:02:46 -0400
Message-ID: <46781A46.9010708@bucksvsbytes.com> (raw)
In-Reply-To: <20070617155441.GB13671@phlogiston.dyndns.org>
References: <4674F357.5040409@bucksvsbytes.com>
<20070617155441.GB13671@phlogiston.dyndns.org>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Andrew Sullivan wrote:
<blockquote cite="mid20070617155441.GB13671@phlogiston.dyndns.org"
type="cite">
<pre wrap="">On Sun, Jun 17, 2007 at 04:39:51AM -0400, John Gunther wrote:
</pre>
<blockquote type="cite">
<pre wrap="">functions and using subqueries without success. I think I need someone
to point me in the right conceptual direction.
</pre>
</blockquote>
<pre wrap=""><!---->
Well, the right SQL-esque conceptual direction is not to have
different tables at all. That's not a very normal-form thing to do,
because the data has been broken into pieces dependent on the data
itself, rather than the kind of data it is.
A
</pre>
</blockquote>
Well, Andrew, you're certainly right but I made an exception because of
the data needs. The real application is a sales tax table, where the
tax jurisdiction can depend on any element of the address hierarchy. In
different areas, it could depend on zip/postal code, city,
state/province, nation, or even street address. I originally considered
storing all address elements in one giant table with parent/child
relationships (zip 11208's parent is Brooklyn, Brooklyn's parent is
Kings County, Kings County's parent is NY, etc but brief analysis
showed that address elements frequently have more than one parent. So I
decided to keep the elements in separate tables (nation, city, street,
zip, etc) to allow more complex relationships. That led me to the sales
tax jurisdiction problem. I could just assign a tax jurisdiction to
every street segment but that would create a daunting data maintenance
problem as it requires propagating jurisdiction changes down through
every segment and ensuring every valid street segment has a record.<br>
<br>
It's an interesting problem.<br>
<br>
Another respondent suggested a programmed function that will do the
job. I was hoping for a pure SQL solution but his approach will
definitely work.<br>
<br>
John<br>
</body>
</html>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: postgresql@bucksvsbytes.com
Subject: Re: joining a table whose name is stored in the primary record
In-Reply-To: <46781A46.9010708@bucksvsbytes.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox