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

Defining FKs in CREATE TABLE–#SQLNewBlogger

Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.

One of the important things that a database developer can do is to define Foreign Keys (FK) at table creation. This is a good time to do this as the referential integrity gets setup before any data is added and this can prevent issues later.

This post shows the syntax for defining the FKs and adding them to your tables immediately.

Build the Reference

The first step is to ensure you have a table with a Primary Key (PK) that will be referenced. Let’s do that first. I’ve been looking to provide a database of SQL Server Builds, so let’s start with a table of versions.

( SQLServerVersionKey INT IDENTITY(1,1)
, VersionName VARCHAR(200)

The PK in this table is what is referenced in the next table. This is required as a FK must refer to a PK in another table.

Add the Reference

When you build a child table, you may write the code like this:

CREATE TABLE [dbo].[SQLServerBuilds]
[BuildKey] [int] NOT NULL IDENTITY(1, 1),
[BuildNumber] [varchar] (30)  NULL,
[BuildDescription] [varchar] (100)  NULL,
[BuildKBArticleNumber] [varchar] (50) NULL,
[BuildKBArticleURL] [varchar] (1000)  NULL,
[SQLServerVersionKey] [int]  NULL

However, in this case, you’ve ignored the FK that might link this table to the versions table. This means that a value could be entered in this table that doesn’t exist in the SQLServerVersion table.

You might think this won’t happen with your application, but thousands, maybe millions, of developers have felt the same way. And they have junk data in their databases because of this.

If there is a strong relationship, add the FK.

Here’s how we do that in the CREATE TABLE statement. I’ll add a comma at the end and include a CONSTRAINT clause. I add the name and then the FOREIGN KEY keywords. Next I include the column from this table that is the FK with the References and the other table and column.

     BuildKey INT NOT NULL IDENTITY(1, 1) ,
     BuildNumber VARCHAR(30) NULL ,
     BuildDescription VARCHAR(100) NULL ,
     BuildKBArticleNumber VARCHAR(50) NULL ,
     BuildKBArticleURL VARCHAR(1000) NULL ,
     SQLServerVersionKey INT NULL ,
     CONSTRAINT SQLServerBuild_Version_FK
         FOREIGN KEY (SQLServerVersionKey)
         REFERENCES dbo.SQLServerVersion (SQLServerVersionKey)

This is the structure I tend to use, though sometimes I’ll move the CONSTRAINT clause directly below the actual column. This lets me see right away this is related to that column.

I also avoid using this inline in the column as I can’t specify the constraint name, which I always want to do.


This is a core skill that database developers needed. If you know the syntax, this post would take about 10  minutes to structure and write. If not, maybe it’s 10 more to learn a bit.. Write your own and show you understand the design concepts.


Creating Foreign Key Relationships – https://docs.microsoft.com/en-us/sql/relational-databases/tables/create-foreign-key-relationships?view=sql-server-2017

The Voice of the DBA

Steve Jones is the editor of SQLServerCentral.com and visits a wide variety of data related topics in his daily editorial. Steve has spent years working as a DBA and general purpose Windows administrator, primarily working with SQL Server since it was ported from Sybase in 1990. You can follow Steve on Twitter at twitter.com/way0utwest


Leave a comment on the original post [voiceofthedba.com, opens in a new window]

Loading comments...