May 15, 2009 at 7:31 am
HI All,
Consider a table Example which has two fields A and B where A is unique and B is not unique. (ie Any two or more value of A field can contain identical B field value). Should we consider combined key or make "A" as primary field.
CREATE TABLE Example
(
A varchar(20) not null,
B varchar(20) not null
)
INSERT INTO Example Values ('A1','B1')
INSERT INTO Example Values ('A2','B2')
INSERT INTO Example Values ('A3','B1')
Now, should I desgin table example with Field A as primary key or should I consider A, B as combined key?
Ta
May 15, 2009 at 8:16 am
Thew fact of choosing keys does not depend only on the uniqueness of the column values (or their combination)... you should consider the essence of your entities and relations to choose the right keys... this process is called normalization
May 17, 2009 at 9:14 pm
Considering the given facts, Column A will have to be the PK. The Column have to be Unique to qualify for PK.
May 18, 2009 at 1:14 pm
PK is a logical design construct used to uniqly identify a tuple of an entity. Physical implementation requires that columns chosen to be PK, should be not null, and have an unique index.
Which columns to include for PK at table level? It should have already been decided during logical design.
Assuming, on the other hand, if you are actually weighing whether to define a single column or composite index - it depends on how your queries are going to access the table. But for the given choices of (A), or (A,B) - I would go with A. A is also unique, which probably means it is also your PK.
May 19, 2009 at 1:22 am
Thank you everyone.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply