pg.ddx.io  pgsql-sql@postgresql.org mailing list archive  

help / color / mirror / Atom feed

question : the choice of the primary key.
2+ messages / 1 participants
[nested] [flat]

* question : the choice of the primary key.
@ 2004-01-06 23:38  Loeke <LoekeDoeLoekeDoe@dontlikespam.hotmail.com>
  0 siblings, 1 reply; 2+ messages in thread

From: Loeke @ 2004-01-06 23:38 UTC (permalink / raw)
  To: pgsql-sql

U have for example something like this

create table persons(
(id..),
surename ..,
familyname ..,
street ..,
..,
birthdate,..
)

a table containing the data of persons, each persons should of course be
present only once;
and one should still define a primary key,
there are two options now,
1.many people make an extra id field and choose this id field to be the
p-key,
but then the same person can be present twice in the table (with different
id fields), the id in itself has no real meaning
2.or u can choose the "natural" key for each person, lets say a name and the
birthdate of a person make that person unique, so lets make (the whole name
en the birthdate) the primary-key; but then if another table X wants to
refer this table of persons using a foreign key, this foreign key exists out
of 3 fields, which smells redundant

u have often this choice in determining the primary keys,

plz give me your opinions, options i overlooked or usefull comments.





^ permalink  raw  reply  [nested|flat] 2+ messages in thread

* Re: question : the choice of the primary key.
@ 2004-01-07 14:17  Loeke <LoekeDoeLoekeDoe@dontlikespam.hotmail.com>
  parent: Loeke <LoekeDoeLoekeDoe@dontlikespam.hotmail.com>
  0 siblings, 0 replies; 2+ messages in thread

From: Loeke @ 2004-01-07 14:17 UTC (permalink / raw)
  To: pgsql-sql

> 1.many people make an extra id field and choose this id field to be the
> p-key,
> but then the same person can be present twice in the table (with different
> id fields), the id in itself has no real meaning
> 2.or u can choose the "natural" key for each person, lets say a name and
the
> birthdate of a person make that person unique, so lets make (the whole
name
> en the birthdate) the primary-key; but then if another table X wants to
> refer this table of persons using a foreign key, this foreign key exists
out
> of 3 fields, which smells redundant

i solved it for now
using a p-key (the short id)
and a a-key (the natural key),
so integrity is ok and refences are short.

>
> u have often this choice in determining the primary keys,
>
> plz give me your opinions, options i overlooked or usefull comments.
>
>





^ permalink  raw  reply  [nested|flat] 2+ messages in thread

end of thread, other threads:[~2004-01-07 14:17 UTC | newest]

Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2004-01-06 23:38 question : the choice of the primary key. Loeke <LoekeDoeLoekeDoe@dontlikespam.hotmail.com>
2004-01-07 14:17 ` Loeke <LoekeDoeLoekeDoe@dontlikespam.hotmail.com>

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