PostgreSQL Discussion - artificial keys or not?

Author

artificial keys or not?

Hannes Dorbath

2005-04-22, 7:23 am

we have lots of small relations that only consist of a few attributes.
like in an ecommerce app we have relations like:

payment_methods
payment_methods_lang

delivery_types
delivery_types_lang

basket_states
basket_states_lang

payment_methods, delivery_types, basket_states mostly just consist of

foo_id serial [PK]
active boolean

the *_lang relations look like

foo_id integer [PK]
language_id integer [PK]
label varchar
description text

The problem is, our queries got a bit unreadable..

SELECT
b.basket_id
FROM
baskets b
WHERE
b.basket_state_id IN (1,3,6,7);

...dosen't tell much, so we came up with an additional attribute called
handle, which is just an alternate key for foo_id.

SELECT
b.basket_id
FROM
baskets b
INNER JOIN basket_states bs USING (basket_state_id)
WHERE
bs.handle IN (
'open',
'sign_pending',
'freight_cost_calc_p
ending',
'expired'
);

looks more readable, but there is need for one more join as well..

...so the only question is:

drop the the serials as PKs and just use short text handles? our
database size is arround 290 mb. there shouldn't be speed issues as long
as proper indexes exit, right? some of the conditions are dynamic
though, so there can't be an proper index in any case. any other concerns?

thanks in advance

Scott Ribe

2005-04-22, 8:23 pm

> ..so the only question is:
>
> drop the the serials as PKs and just use short text handles? our
> database size is arround 290 mb. there shouldn't be speed issues as long
> as proper indexes exit, right? some of the conditions are dynamic
> though, so there can't be an proper index in any case. any other concerns?

Someone (a manager) somewhere (probably marketing) sometime (when you least
expect it) will demand that those short text names be changed, possibly for
a completely irrational reason. I know there are still text books that claim
that artificial keys are evil for some inscrutable reason, but hard
experience has taught me to never, ever, under any circumstance, make a
primary key out of data that comes from humans, and to be very suspicious of
using data that will be visible to humans.

--
Scott Ribe
scott_ribe@killerbyt
es.com
http://www.killerbytes.com/
(303) 665-7007 voice

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Jeff Eckermann

2005-04-25, 11:23 am

"Scott Ribe" < scott_ribe@killerbyt
es.com> wrote in message
news:BE8ED6E7. 21FC1%scott_ribe@kil
lerbytes.com...
>
> Someone (a manager) somewhere (probably marketing) sometime (when you
> least
> expect it) will demand that those short text names be changed, possibly
> for
> a completely irrational reason. I know there are still text books that
> claim
> that artificial keys are evil for some inscrutable reason, but hard
> experience has taught me to never, ever, under any circumstance, make a
> primary key out of data that comes from humans, and to be very suspicious
> of
> using data that will be visible to humans.

This is my experience also. But opinions vary, and I wouldn't be surprised
to see a further post from someone which argues the exact opposite. :-)

>
>
> --
> Scott Ribe
> scott_ribe@killerbyt
es.com
> http://www.killerbytes.com/
> (303) 665-7007 voice
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>

Sponsored Links