Re: Stupid Database Tricks
From: <hasta_l3_at_hotmail.com>
Date: 23 May 2007 11:56:07 -0700
Message-ID: <1179946566.857735.171040_at_n15g2000prd.googlegroups.com>
On 23 mai, 19:23, "daveb" <bestgl..._at_gmail.com> wrote:
> In my experience, the mind-set of developers who auto-id all tables causes
> them to avoid identifying or enforcing appropriate natural keys (whether
> through ignorance or malice, I would hesistate to say). Consequently, there
> will be patients with more than one patient ID. So now the application must
> provide a way to merge them; I submit that this is a much more difficult
> task.
Date: 23 May 2007 11:56:07 -0700
Message-ID: <1179946566.857735.171040_at_n15g2000prd.googlegroups.com>
On 23 mai, 19:23, "daveb" <bestgl..._at_gmail.com> wrote:
>
> In my experience, the mind-set of developers who auto-id all tables causes
> them to avoid identifying or enforcing appropriate natural keys (whether
> through ignorance or malice, I would hesistate to say). Consequently, there
> will be patients with more than one patient ID. So now the application must
> provide a way to merge them; I submit that this is a much more difficult
> task.
Interestingly, I happen to work in the medical field. It is not
unheard of that
the customer organization reuses patient id (and, more frequently,
order
and sample ids)
It is also not unusual for these ids to be assigned hours after
analysis
result have been entered in the database, notably in case of
emergency.
We happen to model such ids as references - that is textual identifications which are unique in a given period of time.
- Raoul