multiple field primary key

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have an interoffice memo table with the first record starting at 001 (primary key). I need to start over at 001 for 2004 without creating a separate table for 2004. Would a multi field primary key consisting of the year (03 or 04) and the record number 001, 002, 003 make sense or is there another way to do this that makes more sense?

Thanks,
Robbie
 
It is perfectly acceptable to have multiple columns as a primary keys
for a table, however there are certains rules that apply to primary
keys that should adhere to make your life as a programmer easier.

First, a primary key should never be changed. By the fact that you are
adding a new field to your table to create a new primary key you are in
essence changing the primary key. This new field will also have to be
added to any child tables associated with this table and all records
will have to be modified.

Second, a primary key should always reflect the table itself. For
example, in an employee table an employee may be uniquely represented
by a social security number. However, there are times where a primary
key for table cannot be found, in that case a false key can be used
instead. If a false key is used it there should never be any
information associated with it ( ie, year, time, business rules, etc.
). The problem with associating information as part of the false
primary key is that this information may change in the future.

Hope this helps.


sajohn52
 
Thanks, I appreciate your response!



----- sajohn52 wrote: -----


It is perfectly acceptable to have multiple columns as a primary keys
for a table, however there are certains rules that apply to primary
keys that should adhere to make your life as a programmer easier.

First, a primary key should never be changed. By the fact that you are
adding a new field to your table to create a new primary key you are in
essence changing the primary key. This new field will also have to be
added to any child tables associated with this table and all records
will have to be modified.

Second, a primary key should always reflect the table itself. For
example, in an employee table an employee may be uniquely represented
by a social security number. However, there are times where a primary
key for table cannot be found, in that case a false key can be used
instead. If a false key is used it there should never be any
information associated with it ( ie, year, time, business rules, etc.
). The problem with associating information as part of the false
primary key is that this information may change in the future.

Hope this helps.


sajohn52
 
Back
Top