0

I have a database in which I have declared a primary key. Later on in implementing the database, I realized that I will have to create an auto-incrementing surrogate key and switch my current primary key to that, as my current primary key will inevidably have multiple occurences. I have scoundered the depths of stack overflow and other sites searching for an answer, but I cannot find a reasonable solution.

Specifically, I am making this database for a fraternity, in which each member is initiated with a unique scroll number. It seemed like a good idea to use the scroll number as the primary key, until I realised that members with more than one major of study will have two tuples (one indicating each major, database has to be in 3NF). That considered, is creating a surrogate key the way to go, or is there a far more reasonable solution to the problem?

James Periquete Fisher
  • 1

1 Answers1

0

You will need a many to many relationship between members and areas of studies. So yes you'll need a surrogate key.

Dan Bracuk
  • 20,699
  • 4
  • 26
  • 43
  • Is that something that can be done without scrapping the entire table and starting over? I'm not sure where the surrogate key would go, since each table already uses the scroll number as a primary/foreign key. – James Periquete Fisher Apr 20 '13 at 19:06