SQL Server 2008: What to set FK as PK? - sql-server

Question

I'm putting together my own database and from examples I've seen, Foriegn Key can also be set as Primary Keys.
I was creating my Tables so that all of my FK were also PK. Is this wrong? When should a FK be a PK? Does it have to be a PK?
Primary Key's make sense in their own table... as the Id and Identity. But when using the Id is another table, does it have to be a PK as well?

Answer 1

A Foreign Key should only be the Primary Key when your trying to create a 1 to 1 or 1 to zero/1 mapping.
Example:
I have a Person table, an Employee table, and a Contractor table. All Employees are people, all Contractors are people and every Person is either an employee or a Contractor
Essentially you would end up with something like this.
In response to your people have multiple addresses you should create an association table. Here is a diagram.
As you can see now every person can have many addresses and since each Employee is a person then every Employee can have many addresses. This is the same for Contractor as well.
Edited: Here is the Change Script from SQL Server
BEGIN TRANSACTION
SET QUOTED_IDENTIFIER ON
SET ARITHABORT ON
SET NUMERIC_ROUNDABORT OFF
SET CONCAT_NULL_YIELDS_NULL ON
SET ANSI_NULLS ON
SET ANSI_PADDING ON
SET ANSI_WARNINGS ON
COMMIT
BEGIN TRANSACTION
GO
CREATE TABLE dbo.Address
(
AddressId bigint NOT NULL,
Address nvarchar(50) NULL,
City nvarchar(50) NULL,
State nvarchar(50) NULL
) ON [PRIMARY]
GO
ALTER TABLE dbo.Address ADD CONSTRAINT
PK_Address PRIMARY KEY CLUSTERED
(
AddressId
) WITH( STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
ALTER TABLE dbo.Address SET (LOCK_ESCALATION = TABLE)
GO
COMMIT
BEGIN TRANSACTION
GO
CREATE TABLE dbo.Person
(
PersonId bigint NOT NULL,
Name nvarchar(50) NULL
) ON [PRIMARY]
GO
ALTER TABLE dbo.Person ADD CONSTRAINT
PK_Person PRIMARY KEY CLUSTERED
(
PersonId
) WITH( STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
ALTER TABLE dbo.Person SET (LOCK_ESCALATION = TABLE)
GO
COMMIT
BEGIN TRANSACTION
GO
CREATE TABLE dbo.PersonAddress
(
PersonId bigint NOT NULL,
AddressId bigint NOT NULL
) ON [PRIMARY]
GO
ALTER TABLE dbo.PersonAddress ADD CONSTRAINT
PK_PersonAddress PRIMARY KEY CLUSTERED
(
PersonId,
AddressId
) WITH( STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
ALTER TABLE dbo.PersonAddress ADD CONSTRAINT
FK_PersonAddress_Person FOREIGN KEY
(
PersonId
) REFERENCES dbo.Person
(
PersonId
) ON UPDATE NO ACTION
ON DELETE NO ACTION
GO
ALTER TABLE dbo.PersonAddress ADD CONSTRAINT
FK_PersonAddress_Address FOREIGN KEY
(
AddressId
) REFERENCES dbo.Address
(
AddressId
) ON UPDATE NO ACTION
ON DELETE NO ACTION
GO
ALTER TABLE dbo.PersonAddress SET (LOCK_ESCALATION = TABLE)
GO
COMMIT
BEGIN TRANSACTION
GO
CREATE TABLE dbo.Employee
(
EmployeeId bigint NOT NULL,
EmployeeNumber nvarchar(50) NULL
) ON [PRIMARY]
GO
ALTER TABLE dbo.Employee ADD CONSTRAINT
PK_Employee PRIMARY KEY CLUSTERED
(
EmployeeId
) WITH( STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
ALTER TABLE dbo.Employee ADD CONSTRAINT
FK_Employee_Person FOREIGN KEY
(
EmployeeId
) REFERENCES dbo.Person
(
PersonId
) ON UPDATE NO ACTION
ON DELETE NO ACTION
GO
ALTER TABLE dbo.Employee SET (LOCK_ESCALATION = TABLE)
GO
COMMIT
BEGIN TRANSACTION
GO
CREATE TABLE dbo.Contractor
(
ContractorId bigint NOT NULL,
ContractorNumber nvarchar(50) NULL
) ON [PRIMARY]
GO
ALTER TABLE dbo.Contractor ADD CONSTRAINT
PK_Contractor PRIMARY KEY CLUSTERED
(
ContractorId
) WITH( STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
ALTER TABLE dbo.Contractor ADD CONSTRAINT
FK_Contractor_Person FOREIGN KEY
(
ContractorId
) REFERENCES dbo.Person
(
PersonId
) ON UPDATE NO ACTION
ON DELETE NO ACTION
GO
ALTER TABLE dbo.Contractor SET (LOCK_ESCALATION = TABLE)
GO
COMMIT

Answer 2

There is only one scenarios that would require a FK to also be a PK.
When the table represents a subclass, or subset, of the things in the PK table, for example, Eg, SalariedEmployees table which has a FK to the Employees table...

Answer 3

A FK is a field pointing to the PK of another table. That's it.
A table linked to itself could contain a FK pointing to its own PK.
A PK that is also a FK can only happen in the child table of a 1 to 1 relationship.

Answer 4

An FK should only also be a PK if the two tables have a one-to-one relationship and the second table was added because the first was too wide and these were items not always needed in most queries.
It will not work at all if you have a one-to-many relationship or a many-to-many relationship.
FKs are much more often not also the PK. If I havea person table and a related address table, If I make the PK and the FK the same thing, then I can only store one address, but most address tables allow for mulitple addresses for the same person or organization. IN that case you would have and AddressID as the PK and a person_id as the FK to the person table. This is the most common PK/FK scenario.

Answer 5

One situation where a given column is both a PK and an FK is the relational model for the gen-spec design pattern. In one of the other responses "Employees" is a specialization of Persons". The PK in the employees tables references the PK in the Persons table. So the PK in the specialized table is also an FK.
This allows the creation of a view that joins employees and persons to provide in a single view all the data about employees, whether that data is peculiar to employees (like "Hire Date") or is common to all persons, whether or not they are employees (like "Date of Birth").
It is not good practice to make every PK also be an FK. The FKs should reflect the logical structure of the data. If the logical model is illogical, you're headed for trouble.