From: | "Richard Broersma" <richard(dot)broersma(at)gmail(dot)com> |
---|---|
To: | "Colin Wetherbee" <cww(at)denterprises(dot)org> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Storing computed values |
Date: | 2008-04-21 19:38:36 |
Message-ID: | 396486430804211238j6c178bdbr95ac49ddcf57dd85@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, Apr 21, 2008 at 12:24 PM, Colin Wetherbee <cww(at)denterprises(dot)org> wrote:
> Right, but the problem I see is that my locations are not actually stored in
> foo. Since many rows of foo can reference the same location, the locations
> are stored in a separate table and, in fact, are referenced by foreign keys
> (SERIAL/INTEGER types) already.
I see, I haven't used PostGIS yet, so I am not sure how it is used.
However, I am curious about the advantages or the intent of having
duplicate points in a table that requires the surrogate ID in order to
be distinguished these duplicate point. I only ask since I am not
familiar with postGIS (perhaps this is the way it is intended to be
used.) To me this seems to be a bit de-normalized, unless there is
something that differentiates or somehow makes these points unique
these points.
If you constrained your data to only allowed unique points in your
points table, your problem would be solved in regards to caching,
since you could simple use natural foreign keys to get the connections
data that you want.
--
Regards,
Richard Broersma Jr.
From | Date | Subject | |
---|---|---|---|
Next Message | Colin Wetherbee | 2008-04-21 19:47:55 | Re: Storing computed values |
Previous Message | Colin Wetherbee | 2008-04-21 19:24:11 | Re: Storing computed values |