Is that possible to creat three primary keys in same table?
- Thread starter Nader
- Start date
Kiwiman
Registered User
- Local time
- Today, 18:45
- Joined
- Apr 27, 2008
- Messages
- 798
Howzit
You can only have one PK in a table. But you can have multiple fields that when combined make your PK.
You can only have one PK in a table. But you can have multiple fields that when combined make your PK.
- In design view of the table click the Indexes button (on the Table Design toolbar).
- Give the Index a name
- Make it the Primary Key
- Select the first column to be included in your unique combination
- Select additional fields directly below your first selection (do not put anything in the name section)
- Local time
- Today, 18:45
- Joined
- Sep 12, 2006
- Messages
- 16,072
1 PRIMARY KEY
but you can have other fields as keys, and make them multi field if necessary
you can then specifiy they are unique also
------
so effectively they work like primary keys - all the primary key does is give the default sort order
but you can have other fields as keys, and make them multi field if necessary
you can then specifiy they are unique also
------
so effectively they work like primary keys - all the primary key does is give the default sort order
- Local time
- Today, 12:45
- Joined
- Feb 28, 2001
- Messages
- 30,566
Depending on your intention, there might be other issues as well.
When you say "three primary keys" you cannot do that - but you could say one of these two possibilities:
a. Three keys, the combination of which must be unique.
b. Three keys, each of which must be individually unique.
The latter case would occur if and only if each of the three keys was originally a candidate for Prime Key (PK) status.
The reason you must choose one of the three as the PK for case (b) is that normalization rules require a record to depend on its PK. That is, every field in the record is an attribute of the single entity represented by that record - and the word "single" in this case is EXTREMELY important. The PK must uniquely indicate one and only one record. (It's a definition of PK, among other things.)
In case (b) you select one of the three keys as PK and make unique indexes (that aren't the PK) on the other two fields individually.
If you have case (a) on the other hand, the combination the three fields is unique but the values allowed in the individual fields is not necessarily unique. You do NOT build separate and independent indexes for the three fields. In that case, the advice given earlier is spot-on. Make one PK out of the combined fields.
When you say "three primary keys" you cannot do that - but you could say one of these two possibilities:
a. Three keys, the combination of which must be unique.
b. Three keys, each of which must be individually unique.
The latter case would occur if and only if each of the three keys was originally a candidate for Prime Key (PK) status.
The reason you must choose one of the three as the PK for case (b) is that normalization rules require a record to depend on its PK. That is, every field in the record is an attribute of the single entity represented by that record - and the word "single" in this case is EXTREMELY important. The PK must uniquely indicate one and only one record. (It's a definition of PK, among other things.)
In case (b) you select one of the three keys as PK and make unique indexes (that aren't the PK) on the other two fields individually.
If you have case (a) on the other hand, the combination the three fields is unique but the values allowed in the individual fields is not necessarily unique. You do NOT build separate and independent indexes for the three fields. In that case, the advice given earlier is spot-on. Make one PK out of the combined fields.
Similar threads
