>That's not _quite_ what I meant. The primary keys I assign are never
>seen by the user. The user generally assigns a candiate id manually.
>This one actually _could_ be FOSTEDON01. Since the primary key is 185423,
>and this is the value that's stored in all tables referencing PatientID,
>we can change FOSTEDON01 to FITZGEDON01 in the Patient table, and not
>have to make any further changes.

Just to add more...

A primary key should always represent something for the database design but not for the user's side.

It's true that in mose cases, the client will probably use another key, like the file number of a specific client.

Also, even if we don't expect to have relationship, it is always a good idea to start at the beginning with a primary key in case we need to implement relationships.

Even without relationship, the application should use a primary key to locate the record instead of the user key.