When working with SQL tables, you'll often need to set constraints on the data types stored in a specific table. For instance, if you have a table with employee data, it's logical that some fields should not contain null values. You can apply such a constraint to the SQL values with a simple command. You can also require that entered values be unique or that data be checked against certain conditions. In this article, we'll look at how to do this and cover all possible types of constraints, but first, let's start with some terminology.
An SQL constraint is a rule that we apply to fields in SQL, determining which values are allowed and which are not. After adding a constraint, the program will check whether it's possible to insert, update, or delete data in the table based on the user-defined constraints. If not, the operation will not be executed, and the program will return an error. Now, let's explore all possible types of constraints in SQL databases, and for clarity, we'll provide examples that could be practically useful for you.
You can create SQL constraints using the following commands: PRIMARY KEY
, FOREIGN KEY
, UNIQUE
, CHECK
, and NOT NULL
.
The NOT NULL
constraint ensures that a column must have a value for every record, meaning the value cannot be null. This prevents empty values from being stored in the column. Let's create a table with a column that has this constraint:
CREATE TABLE Countries (
Country VARCHAR(46) NOT NULL,
Capital VARCHAR(46)
)
Here, we allow the name of the country's capital to be omitted, but the name of the country must always be provided. Let's try to add a record that violates this rule:
INSERT INTO Countries VALUES (null, 'Madrid')
It will result in this error:
Column 'Country' cannot be null
However, this record will not trigger an error because we did not prohibit leaving the capital name (Capital
) column empty:
INSERT INTO Countries VALUES ('Spain', null)
The NOT NULL
constraint can be useful for columns with contact information when we need to require the user to enter their email address or phone number, for example. Therefore, such mandatory fields often use the NOT NULL
constraint to ensure that the user enters a specific value:
CREATE TABLE Subscribers (
SubscriberName VARCHAR(46) NOT NULL,
SubscriberContact VARCHAR(46) NOT NULL,
)
In this case, we require users to obligatorily enter their name and email address, setting a 64-character limit for each field in the table. Specifying character limits for certain fields can also be useful to prevent the addition of invalid data. This operation is often applied for efficiency so the database size is not unnecessarily inflated.
This constraint’s name fully reflects its essence. The UNIQUE
constraint ensures that no two values in the specified column will be the same. Let’s take a look at a table where UNIQUE
is used:
CREATE TABLE Workers1 (
WorkerName VARCHAR(46) NOT NULL,
WorkerDate DATE,
WorkerContact INTEGER UNIQUE
)
We created an employee table, where we will add the employee's name (the field cannot be empty, as we have already set the familiar NOT NULL
constraint), the hire date (in date format, indicated by the DATE
data type), and the phone number. The phone number must be unique, as indicated by the UNIQUE
constraint. Let’s insert the following data into our table:
INSERT INTO Workers1 VALUES ('John Smith', DATE '2018-05-10', 375123456789)
Now, when trying to insert a row with the same phone number:
INSERT INTO Workers1 VALUES ('James Smith', DATE '2020-06-11', 375123456789)
The program will throw an error:
Duplicate entry 375123456789 for key 'uniqueconstraint.WorkerContact'
The UNIQUE
constraint is ideal for columns that should not contain duplicate values. For example, each of us has a unique social security number. Therefore, if a table contains a column for SSN, it should use the UNIQUE
constraint. This is necessary to avoid two people having the same numbers, which could be inserted by mistake or intentionally.
The CHECK
constraint is used to validate values based on a specific condition. Consider the following example:
CREATE TABLE Customers1 (
CustomerName1 VARCHAR(46),
CustomerName2 VARCHAR(46),
CustomerEmail VARCHAR(56),
CustomerAge INTEGER CHECK (CustomerAge>17)
)
We have set an age constraint where the age must be greater than 17. Now, let’s see what happens when a customer enters the following data:
INSERT INTO Customers1 VALUES ('John', 'Smith, '[email protected]', 17)
That’s what we’ll see:
Check constraint 'checkconstraint_chk_1' is violated
The CHECK
constraint can be used to implement custom rules. For example, if a table should only store data for adults, we could use the CHECK
constraint for the CustomerAge
column (CustomerAge > 17
, as shown in the example above). Another example: if the table should only store data for Cyprus citizens, we could use CHECK
for a new column CustomerCountry
: CHECK (CustomerCountry = 'Cyprus')
.
PRIMARY KEY
is one of the table key constraints in SQL, specifically the primary key. It is used to create an identifier that corresponds to each row in the table. Additionally, a PRIMARY KEY
can only apply to one column in a table (since it serves as the identifier). Therefore, each PRIMARY KEY
value must be unique, and null values are not allowed in the column defined by the PRIMARY KEY
. To better understand this, let’s look at the following example:
CREATE TABLE Workers2 (
id INTEGER PRIMARY KEY,
WorkerName1 VARCHAR(46),
WorkerName2 VARCHAR(46),
WorkerAge INTEGER CHECK (WorkerAge>17)
)
As we can see, the PRIMARY KEY
constraint allows us to assign an employee ID, so that each record can be referenced using a unique numeric key. Also, notice the familiar CHECK
constraint in the age column.
A FOREIGN KEY
constraint creates a reference to a PRIMARY KEY
from another table. Therefore, a column with a FOREIGN KEY
points to the PRIMARY KEY
column from another table, linking the current table to it through this constraint. To better understand what this key does, let’s look at an example of a FOREIGN KEY
constraint linked to the PRIMARY KEY
from the previously created table:
CREATE TABLE WorkersTaxes (
WorkerTax INTEGER,
Worker_id INTEGER,
FOREIGN KEY (Worker_id) REFERENCES Workers2(id)
)
So, we needed to create a table for calculating workers' taxes. To link this table (WorkersTaxes
) with the workers' table (Workers2
), we used a FOREIGN KEY
reference, which identifies workers based on the PRIMARY KEY
from the Workers2
table. This way, we achieved data consistency, and now each employee can easily be identified in both tables by the linked keys.
We should also note that the SQL Standard sometimes includes DEFAULT
as a constraint; however, DEFAULT
does not restrict the type of data entered, so technically it is not considered a constraint. Nevertheless, it is important to mention here because it enables a crucial function: setting default values when users do not input data. This can be useful, for example, to avoid potential errors when data is not entered. Let’s consider the following example:
CREATE TABLE Customers2 (
CustomerName1 VARCHAR(46) NOT NULL,
CustomerName2 VARCHAR(46) NOT NULL,
CustomerAge INTEGER DEFAULT 18,
)
Now, if the customer does not provide an age, it will be automatically set. And we required the customer to enter their first and last name using the already familiar NOT NULL
constraint.
We hope you now understand how to use each SQL constraint and the benefits they offer. Good luck with your work!