SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Which table to choose to hold foreign key reference


Which table to choose to hold foreign key reference

Author
Message
thinkerinside
thinkerinside
Forum Newbie
Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)

Group: General Forum Members
Points: 3 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?
Grant Fritchey
Grant Fritchey
SSC Guru
SSC Guru (93K reputation)SSC Guru (93K reputation)SSC Guru (93K reputation)SSC Guru (93K reputation)SSC Guru (93K reputation)SSC Guru (93K reputation)SSC Guru (93K reputation)SSC Guru (93K reputation)

Group: General Forum Members
Points: 93294 Visits: 33002
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 Query Performance Tuning and SQL Server Execution Plans
Product Evangelist for Red Gate Software
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search