Monday 18 February 2013

Difference between Primary Key and Foreign Key

In SQL Server, there are two keys - primary key and foreign key which seems identical, but actually both are different in features and behaviours. In this article, I would like to share the key difference between primary key and foreign key. For more help about keys in SQL Server refer the article Different Types of SQL Keys.
Difference between Primary Key & Foreign Key
Primary Key
Foreign Key
Primary key uniquely identify a record in the table.
Foreign key is a field in the table that is primary key in another table.
Primary Key can't accept null values.
Foreign key can accept multiple null value.
By default, Primary key is clustered index and data in the database table is physically organized in the sequence of clustered index.
Foreign key do not automatically create an index, clustered on non-clustered. You can manually create an index on foreign key.
We can have only one Primary key in a table.
We can have more than one foreign key in a table.

Define Primary key and Foreign key

  1. --Create Parent Table
  2. CREATE TABLE Department
  3. (
  4. DeptID int PRIMARY KEY, --define primary key
  5. Name varchar (50) NOT NULL,
  6. Address varchar(100) NULL
  7. )
  8. GO
  9. --Create Child Table
  10. CREATE TABLE Employee
  11. (
  12. EmpID int PRIMARY KEY, --define primary key
  13. Name varchar (50) NOT NULL,
  14. Salary int NULL,
  15. --define foreign key
  16. DeptID int FOREIGN KEY REFERENCES Department(DeptID)
  17. )

Note

As @Marc Jellinek suggested, I would like to add the below points about foreign key :
  1. Foreign keys do not automatically create an index, clustered on nonclustered. You must manually create an index on foreign keys.
  2. There are actual advantages to having a foreign key be supported with a clustered index, but you get only one per table. What's the advantage? If you are selecting the parent plus all child records, you want the child records next to each other. This is easy to accomplish using a clustered index.
  3. Having a null foreign key is usually a bad idea. In the example below, the record in [dbo].[child] is what would be referred to as an "orphan record". Think long and hard before doing this.
  1. IF EXISTS (SELECT * FROM [sys].[schemas] [sch] INNER JOIN [sys].[tables] [tbl] ON [sch].[schema_id] = [tbl].[schema_id] WHERE [sch].[name] = 'dbo' AND [tbl].[name] = 'child')
  2. DROP TABLE [dbo].[child]
  3. IF EXISTS (SELECT * FROM [sys].[schemas] [sch] INNER JOIN [sys].[tables] [tbl] ON [sch].[schema_id] = [tbl].[schema_id] WHERE [sch].[name] = 'dbo' AND [tbl].[name] = 'parent') DROP TABLE [dbo].[parent]
  4. CREATE TABLE [dbo].[parent]
  5. (
  6. [id] [int] IDENTITY NOT NULL,
  7. [name] [varchar](250) NOT NULL,
  8. CONSTRAINT [PK_dbo__parent] PRIMARY KEY NONCLUSTERED ([id])
  9. )
  10. CREATE TABLE [dbo].[child]
  11. (
  12. [id] [int] IDENTITY NOT NULL, [parent_id] [int] NULL,
  13. [name] [varchar](250) NOT NULL,
  14. CONSTRAINT [PK_dbo__child] PRIMARY KEY NONCLUSTERED ([id]),
  15. CONSTRAINT [FK_dbo__child__dbo__parent] FOREIGN KEY ([parent_id]) REFERENCES [dbo].[parent]([id])
  16. )
  17. --Insert data
  18. INSERT INTO [dbo].[parent] ([name]) VALUES ('parent1')
  19. INSERT INTO [dbo].[child] ([parent_id], [name])VALUES(1, 'child 1')
  20. INSERT INTO [dbo].[child] ([parent_id], [name])VALUES(NULL, 'child 2')
  21. --Select data
  22. SELECT * FROM [dbo].[child]

 

No comments:

Post a Comment