On Thu, Apr 28, 2011 at 3:07 PM, Karsten Hilbert
<Karsten.Hilbert@gmx.net> wrote:
> I must agree with a recent poster
> that what appears to identify as a natural key often really
> isn't or else becomes not so later on. It's vastly easier to
> then deal with that by re-defining constraints without
> having to touch primary keys.
I have run into this. Often what happens is that the data model
directly affects the assumptions coders make. In a system I worked
on, the username was unique / primary key. Code was written that
assumed username would always be unique across the app. Then the app
was deployed to multiple non-associated groups, where user names from
two different organizations might be the same and they couldn't be
changed. Talk about some ugly code changes needed to be made to fix
all the bugs. ugh. An initial assumption that a serial value would
be unique, but usernames might not be would have resulted in a much
cleaner design for that system. Or even that the PK was org||username
or something.
