OT--database design forgot about twins

[Gary Walter]

I am a twin. Luckily, my father's insurance
was not provided by Sun Life Canada....

"... our system cannot handle two people
with the same last name born in the same month
of the same year on the same plan."

http://thedailywtf.com/Articles/Disjoint_Twins.aspx

 

[John Vinson]

I am a twin. Luckily, my father's insurance
was not provided by Sun Life Canada....

"... our system cannot handle two people
with the same last name born in the same month
of the same year on the same plan."

http://thedailywtf.com/Articles/Disjoint_Twins.aspx

wow.... same MONTH!? and same LAST NAME???

So they probably don't want any business from people named Smith or
Jones...

John W. Vinson[MVP]

 

[Baz]

An object lesson in why you should use autonumbers instead of natural keys
LOL!

 

[RoyVidar]

An object lesson in why you should use autonumbers instead of natural
keys LOL!

If you read the article, you will find that there is no problem
entering the twins with correct date of birth. If natural primary
key had been the issue, that wouldn't be allowed.

Since this is connected to the installation of new software, I think
it's more likely that the developers of the new software version,
are the ones who screwed up, and then, since entring the twins isn't
restricted, that the error is in the client/application, rather than
problems with the database design.

One of the possible failures here, could be that they are using
surrogate keys, but that they didn't provide enough fields for the
user, or automated claim processing to identify the correct twin
(for instance by not providing first name together with the rest of
the mentioned fields), so that the user or process just proceeds with
the first match.

I'm curious of why this article is a lesson in why one should use
autonumbers over natural keys, as I'm not able to read what kind of
primary key structure they are using.

I would find it more likely to be a application/client issue than
database design issue - unless the error is that there's no primary
key at all.

 

[Baz]

Doh, it was a JOKE!!!

If you read the article, you will find that there is no problem
entering the twins with correct date of birth. If natural primary
key had been the issue, that wouldn't be allowed.

Since this is connected to the installation of new software, I think
it's more likely that the developers of the new software version,
are the ones who screwed up, and then, since entring the twins isn't
restricted, that the error is in the client/application, rather than
problems with the database design.

One of the possible failures here, could be that they are using
surrogate keys, but that they didn't provide enough fields for the
user, or automated claim processing to identify the correct twin
(for instance by not providing first name together with the rest of
the mentioned fields), so that the user or process just proceeds with
the first match.

I'm curious of why this article is a lesson in why one should use
autonumbers over natural keys, as I'm not able to read what kind of
primary key structure they are using.

I would find it more likely to be a application/client issue than
database design issue - unless the error is that there's no primary
key at all.