From: | Tim Uckun <timuckun(at)gmail(dot)com> |
---|---|
To: | Julian <tempura(at)internode(dot)on(dot)net> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Using varchar primary keys. |
Date: | 2013-04-01 05:17:36 |
Message-ID: | CAGuHJrN2y6FTeMrAT4kzQX2NU4RteEnxs+EwhrJxO3fygSH77w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
>
>
> Natural Keys have a purpose but when do they exist in the database?
>
>
In my case it's the tags. Table tags has only two columns id and tag. Each
one has a unique index. I have many other similar lookup tables. For
example things like order_status, item_type etc.
> What about the Natural Keys of an external source? Should that be stored
> in a lookup table along with the integer based Surrogate Key?
> Maybe I'll call it "bars_pks".
>
>
I always keep those. The API's I expose to clients and partners allow them
to modify the records they send and I let them refer to items by their own
primary keys. This has always worked out well for me.
>
> --Spelling error.
>
> UPDATE tags SET tag = 'foo' WHERE tag = 'fu';
>
> This will fail unless you ON UPDATE CASCADE.
>
>
Yes of course you'd need the on update cascade. Then again maybe I don't
even need that tags table. Tags could just be a view (select distinct tag
from child_tags). I am not saying that's efficient or desirable but it's
possible.
From | Date | Subject | |
---|---|---|---|
Next Message | Jasen Betts | 2013-04-01 05:58:05 | Re: Using varchar primary keys. |
Previous Message | Julian | 2013-04-01 03:09:28 | Re: Using varchar primary keys. |