By: Greg Robidoux | Last Updated: 2007-05-04 | Comments (1) | Constraints
One design aspect that all tables should have is a primary key. The primary key is the main entry way into your dataset, so that when you access your data you are guaranteed to only affect one row of data. Having primary keys are not only a good design feature they also play an important role in replication and data updates especially when there may be duplicate rows of data. So how can you determine what tables have primary keys and what tables do not have primary keys?
As mentioned above, primary keys guarantee a unique row of data in your table. Some of the design aspects of a primary key are as follows:
- can be one or more columns
- column values can not be null
- the column or combination of columns must be unique
- there can only be one primary key on a table
In the past there have been other tips that focus on all indexes that exist in the database, but here we will take a different look at tables that have primary keys and tables that do not have primary keys. For SQL 2005 this is pretty easy to do now ,by using the sys.key_constraints catalog views, but with SQL 2000 it is a bit cryptic to get this information.
Query 1 - Tables with primary keys
Query 2 - Tables without primary keys
- Now that you have these queries take the time to identify where primary keys may be missing
- As a good design rule you should always create a primacy key for all of your tables
- If you don't have a good candidate for a primary key in your table then look at using an identity column just for this purpose
Last Updated: 2007-05-04
About the author
View all my tips