Surrogate key versus natural key

Results 1 to 2 of 2

Thread: Surrogate key versus natural key

  1. #1
    Join Date
    Dec 1969

    Default Surrogate key versus natural key

    I have read a few articles and I still do not know what is correct. I am trying to decide whether or not to use an autoincrement field as my primary key or a unique custom code as my primary key. Here is the reason. If you change the custom code and have cascade updates you still have the same results as if you have an autonumber primary key and just change the custom code in the 1 to many table. <BR><BR>So is there any reason to every use anything other than autonumber fields as your primary key since many articles say use a primary key that has no meaning since those fields meanings could change over time?

  2. #2
    Join Date
    Dec 1969
    Indianapolis, IN

    Default RE: Surrogate key versus natural key

    If you already have a field in the table that will never change, then you don&#039;t need the autonumber. For example, if you use social security numbers, those don&#039;t change. Or you may assign an employee number to people that&#039;s not an autonumber (perhaps HR gives you the number). Same could be true with other data. But you are correct in that if there is any possibility of data changing, use the autonumber for the PK. This all assumes that you want a PK in your table of course.

Posting Permissions

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