Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 166
  • Last Modified:

Composite primary key

I have the following table
EmployeeTable
EmpId int
CompanyId int
EmpType char(20)
Name varchar(50)
Address varchar(50)
Dob Date
JoinDate Date
.....,,,,
EmpId, companyid, EmpType are the composite primary keys of the table. Should composite primary keys always be at top of the column list and one next to one OR can it be in the any position ? What are the advantages of making composite primary key in top of the column list one next one?
0
Varshini S
Asked:
Varshini S
3 Solutions
 
Vitor MontalvãoMSSQL Senior EngineerCommented:
As much as I know the order is not important at all so I can't say there is any advantage or disadvantage in having columns ordered but for view purpose only.
0
 
ste5anSenior DeveloperCommented:
I'd prefer my key columns to be in top of the column layout. But this is not necessary at all. I makes reading easier, as you can see the relevant columns at a glance.

btw, I don't think that your composite key of EmpId, companyid, EmpType is "correct".
0
 
Varshini SAuthor Commented:
ste5an,
Why the composite  key is not correct ?
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
Vitor MontalvãoMSSQL Senior EngineerCommented:
"correct" and not correct :)

Means that you aren't following the good practices for PK definition. You should avoid description fields. In this case EmpType.
Why you have a CompanyID and don't have a EmpTypeID?
0
 
Éric MoreauSenior .Net ConsultantCommented:
the shorter your primary key is, the best it is. You normally select just what it takes to make it unique
0
 
ste5anSenior DeveloperCommented:
The table is named Employee. Thus I would expect that each row descibes exactly one employee. But your composite key allows this:

CREATE TABLE #Employees
    (
      EmpId INT ,
      CompanyId INT ,
      EmpType CHAR(20) ,
      Name VARCHAR(50) ,
      Dob DATE ,
      JoinDate DATE ,
      CONSTRAINT PK_Employees PRIMARY KEY ( EmpId, CompanyId, EmpType )
    );

INSERT  INTO #Employees
VALUES  ( 1, 1, 'Manager', 'I am Weasle', GETDATE(), GETDATE() ),
        ( 1, 2, 'CEO', 'I am Weasle', GETDATE(), GETDATE() ),
        ( 1, 3, 'Trainee', 'I are Baboon', GETDATE(), GETDATE() );

DROP TABLE #Employees;

Open in new window


So derived from the naming, I think it's a violation of at least 2NF.

As you're using SQL Server, you should take a look at the HumanResources schema of AdventureWorks.
0

Featured Post

Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now