Re: Primary keys for companies and people - Mailing list pgsql-general

From David Goodenough
Subject Re: Primary keys for companies and people
Date
Msg-id 200602021036.55228.david.goodenough@btconnect.com
Whole thread Raw
In response to Re: Primary keys for companies and people  ("Leif B. Kristensen" <leif@solumslekt.org>)
Responses Re: Primary keys for companies and people  (Martijn van Oosterhout <kleptog@svana.org>)
Re: Primary keys for companies and people  (Merlin Moncure <mmoncure@gmail.com>)
List pgsql-general
On Thursday 02 February 2006 09:07, Leif B. Kristensen wrote:
> On Thursday 02 February 2006 09:05, Michael Glaesemann wrote:
> >For people I'm more or less stumped. I can't think of a combination
> >of things that I know I'll be able to get from people that I'll want
> >to be able to add to the database. Starting off we'll have at least
> >7,000 individuals in the database, and I don't think that just family
> >and given names are going to be enough. I don't think we'll be able
> >to get telephone numbers for all of them, and definitely aren't going
> >to be getting birthdays for all.
> >
> >I'm very interested to hear what other use in their applications for
> >holding people and companies.
>
> I've been thinking long and hard about the same thing myself, in
> developing my genealogy database. For identification of people, there
> seems to be no realistic alternative to an arbitrary ID number.
>
> Still, I'm struggling with the basic concept of /identity/, eg. is the
> William Smith born to John Smith and Jane Doe in 1733, the same William
> Smith who marries Mary Jones in the same parish in 1758? You may never
> really know. Still, collecting such disparate "facts" under the same ID
> number, thus taking the identity more or less for granted, is the modus
> operandi of computer genealogy. Thus, one of the major objectives of
> genealogy research, the assertion of identity, becomes totally hidden
> the moment that you decide to cluster disparate evidence about what may
> actually have been totally different persons, under a single ID number.
>
> The alternative is of course to collect each cluster of evidence under a
> separate ID, but then the handling of a "person" becomes a programmer's
> nightmare.
>
> I have been writing about my genealogy data model here:
> <url:http://solumslekt.org/forays/blue.php> The model has been slightly
> modified since I wrote this; due to what I perceive as 'gotchas' in the
> PostgreSQL implementation of table inheritance, I have dropped the
> 'citations' table. Besides, I've dropped some of the surrogate keys,
> and more will follow. I really should update this article soon.
>
> I should perhaps be posting this under another subject, but I feel that
> beneath the surface, Michael's problem and my own are strongly related.
There is also the problem that a name can change.  People change names
by deed-poll, and also women can adopt a married name or keep their old
one.  All in all an ID is about the only answer.

David

pgsql-general by date:

Previous
From: Richard Huxton
Date:
Subject: Re: NULL values and string
Next
From: Silas Justiniano
Date:
Subject: Indexes again