Database Design Question

Results 1 to 2 of 2

Thread: Database Design Question

  1. #1
    Join Date
    Dec 1969

    Default Database Design Question

    I would like peoples opinions on a database design issue. I have always been a big fan of using an arbitrary (usually auto number) unique identifier as the PK in most of my database tables.<BR><BR>Take a common example of a database that needs to store an Employee name, Social Security Number, Date he/she was hired, and Job Title, Project he/she is currently working on, Department he/she is in.<BR><BR>Many tutorials I have read would say to use the Social Security Number as a PK, Or if the database did not store the Social Security Number than a combination of Employee name and Date he/she was hired.<BR><BR>I on the other hand would just slap an Employee ID filed in there. That way I could be 100% sure it was unique. I have also found that it is handy to have a arbitrary ID number for most tables.<BR><BR>For example if I wanted to publish the employees names on the web in a nice little table and when you clicked on each employees name it would display a page with info about the employee such as job title, project he/she is working on, and department he/she is in. So I would need some way of passing the PK though a post or query string to the info display page. If I used the Social Security number as a PK I would then have to pass this info though a hidden field (huge security risk). With an employee ID I could safely pass that info over the web because it would be meaningless to any viewer. <BR><BR>I seem to use Unique ID&#039;s in almost all my tables unless its obviously not needed. I have read several articles that seem to despise the idea of using artificial values in a database.<BR><BR>My question is do you think this is a bad practice? If so what other solution would you recommend for the above problem.<BR><BR>Thanks <BR>David<BR>

  2. #2
    Join Date
    Dec 1969

    Default I will just say...

    ...that a lot of those articles were written by people with zero web-based experience. I think you could get sued over exposing a SSN to outside users, meaning your scheme might save you a lot of money in the long run.<BR><BR>[I will also say that I see nothing wrong with having *multiple* indexes on a table, with "must be unique" constraints on more than one. Such as on both the autonumber PK and the SSN field.]<BR><BR>

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts