The Secrets of Indexes and Foreign Keys

Indexes and foreign keys are great tools when confronted with large databases. They can be the answer to a good design and great performance. In this article, I will go through some tips that helped me understand how to use these tools efficiently and streamline my work with complex databases.

Every image example was done with DbSchema. I enjoy this tool because it is diagram oriented, integrates many features, and has a very good price. 

Foreign Keys

It’s a common mistake to avoid creating foreign keys in a database because they negatively impact the performance. It is true that foreign keys will impact INSERT, UPDATE and DELETE statements because they are data checking, but they improve the overall performance of a database. 

The main benefit of foreign keys is that they enforce data consistency, meaning that they keep the database clean. 

As an example, consider the two tables below. If the two are missing foreign keys, and we delete a department, then the employees associated with it will remain in the employee table as “bad records”. These scenarios happens very often and leads to a database full of junk that decreases performance.  

Without foreign keys: 

With foreign keys:

Indexes

An index for a database is like a table of contents for a book. Searching for data based on a column that is part of the index will allow us to make use of the index to quickly access the record. 

Consider the employee table with an index on firstname. Executing the query bellow will use this index.

xxxxxxxxxx

SELECT * from employees WHERE firstname = ?

Important things to know about indexes:

Databases Only Use One Index per Table and Query

Let's say we create two indexes on the employee table, idx_firstname and idx_lastname. If we execute the query below, the database will decide to use only one of the two indexes. 

xxxxxxxxxx

 SELECT * from employees WHERE firstname = ? and lastname=? 

Index Comparison

When executing a query, the database will compare the indexes with regard to the number of different entries that they contain. 

For example, if we have 2,000 different records in for firstname and 5,000 different records for lastname, it is more probable that using the lastname index will return a smaller number of rows that fit our search criteria. Therefore, it will use that index. 

Composite Indexes

An index that contains two or more columns is a composite index. When using a composite index, the query should always contain the first column of the index.

For example, consider we have the index idx(firstname, lastname). This index will work perfectly on the next query

xxxxxxxxxx

SELECT * from employees WHERE firstname = ? and lastname=?

But won’t work for this one

xxxxxxxxxx

SELECT * from employees WHERE lastname=?

Clustered Indexes

Giving the analogy from the beginning, in a clustered index, the table of contents is located at the end of the book. In a non-clustered index, the table of contents is located in a different place, outside the book. Clustered indexes are recommended when you have fewer updates in your data. 

When creating a clustered index, the table itself becomes the index. 

On the left side of the employees table, we can see how the indexes have different notations. The employee_id is a primary key, firstname and lastname form a composite index, while deparment_id is a unique index. 

Conclusion

Foreign keys are very useful for keeping a database clean and won't affect the SELECT statements. Indexes help you quickly browse the database and find the data you need. Knowing how and when to use them will improve database performance and make your work easier.