Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

Which table to choose to hold foreign key reference Expand / Collapse
Author
Message
Posted Friday, April 18, 2014 1:20 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, April 18, 2014 2:11 AM
Points: 1, Visits: 1
I am creating two tables employeePersonalDetails and employeeSalaryDetails in two different ways i.e., 1. employeeSalaryDetails maintains foreign key that references the primary key in employeePersonalDetails

create table employeePersonalDetails
(
employeeId int,
employeeName varchar(30),
employeeAddress varchar(255),
primary key (employeeId)
);

create table employeeSalaryDetails
(
employeeId int,
employeeSalary int,
primary key (employeeId),
foreign key(employeeId) references employeePersonalDetails(employeeId)
);

2. employeePersonalDetails maintains foreign key that references the primary key in employeeSalaryDetails

create table employeeSalaryDetails
(
employeeSalaryId int,
employeeSalary int,
primary key (employeeSalaryId),
);

create table employeePersonalDetails
(
employeeId int,
employeeName varchar(30),
employeeAddress varchar(255),
employeeSalaryId int,
primary key (employeeId),
foreign key(employeeSalaryId) references employeeSalaryDetails(employeeSalaryId)
);

My question here is: what factors would influence the decision to choose one of these implementations?
Post #1562927
Posted Friday, April 18, 2014 5:09 AM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Friday, July 25, 2014 3:11 PM
Points: 15,517, Visits: 27,898
I'm not crazy about either approach. I prefer what you've done in the first approach. An employee has one or more salaries, so the Employee table (Not sure I'd call it EmployeePersonalDetails and if I did, I'd name the primary key after that name, not EmployeeID, clarity is your best friend) is the parent table and the salary table is the child. The foreign key would then go on the Salary table.

But...

Having the Employee ID be the primary key on the salary table doesn't work. I'm assuming you want a salary table in order to store salary changes over time (otherwise, it'd just be a column in the Employee table). So, you can't just have it be EmployeeID. You need an additional column, SalaryEffectiveDate or something, to differentiate a given salary for a given employee.

So, if you differentiate the primary key on the child table and make the relationship there the way you have it defined, option 1.


----------------------------------------------------
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood..." Theodore Roosevelt
The Scary DBA
Author of: SQL Server 2012 Query Performance Tuning
SQL Server 2008 Query Performance Tuning Distilled
and
SQL Server Execution Plans

Product Evangelist for Red Gate Software
Post #1562966
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse