{"id":179576,"date":"2024-05-13T20:31:51","date_gmt":"2024-05-13T19:31:51","guid":{"rendered":"https:\/\/liora.io\/en\/?p=179576"},"modified":"2026-08-09T19:40:13","modified_gmt":"2026-08-09T18:40:13","slug":"unlocking-the-power-of-sql-foreign-keys-definition-and-applications","status":"publish","type":"post","link":"https:\/\/liora.io\/en\/unlocking-the-power-of-sql-foreign-keys-definition-and-applications","title":{"rendered":"Unlocking the Power of SQL Foreign Keys: Definition and Applications"},"content":{"rendered":"\n

If you’re designing an SQL database management system, it’s in your interest to know and implement the foreign key system. In the long term, it’s a win-win situation.<\/strong><\/p>\n\n\n

A foreign key is a column (or several columns) in a database<\/a> that is linked to the primary key column of another table. The primary key in question is a simple identifier. The useful information , which is subject to change , is contained in the external table.<\/p>\n\n\n

What use is a foreign key?<\/h2>\n\n\n

Let’s imagine you’re managing an Articles table,<\/strong> in which there’s a column called Category. For each item, this category must be filled in individually.<\/p>\n\n\n

For example, we might have a category called “Metal product”. However, from one day to the next, legislation changes and this category becomes “Metal-based product”.<\/strong><\/p>\n\n\n

What do we do now? Will we have to modify all the lines in which the “Metal product” category appears? Unfortunately, yes. If the Articles table covers tens of thousands of entries, the procedure will be tedious, to say the least.<\/p>\n\n\n

It’s to avoid this kind of situation that the notion of foreign key has been defined. So, in the case mentioned above, the idea is to create a separate table, called Category, in which the primary key is an identifier (a number for each category) associated with the corresponding description.<\/p>\n\n\n

From there, in the Articles table,<\/strong> all we need to do is indicate, for each product offered in the catalog, the corresponding identifier from the Categories table.<\/p>\n\n\n

It will then be possible to print the list of each item while displaying (thanks to a join) the corresponding category.<\/p>\n\n\n

So, as we can see, the situation of the category that changes its name is solved here.<\/p>\n\n\n

Parent and daughter table<\/h2>\n\n\n

A “parent table” is one that is referenced by another table. This would be the case here of the Categories table.<\/strong><\/p>\n\n\n

And we speak of a “daughter table” for one that refers to an external table , which would be the case here of the Articles table.<\/p>\n\n\n

A practical example<\/h2>\n\n\n

Here’s another example of the use of a foreign key in a more explicit case.<\/p>\n\n\n

CLIENTS table<\/h3>\n\n\n
\n\n\n\n\n\n<\/colgroup>\n\n\n\n\n\n\n\n
Id_Client<\/th>\nName <\/th>\nFirst Name <\/th>\nAge <\/th>\n<\/tr>\n<\/thead>\n
1<\/td>\nMartin <\/td>\nGermaine <\/td>\n32 <\/td>\n<\/tr>\n
2 <\/td>\nCulprit <\/td>\nThomas <\/td>\n22 <\/td>\n<\/tr>\n
3 <\/td>\nAlbanez <\/td>\nFrancis <\/td>\n40 <\/td>\n<\/tr>\n
4 <\/td>\nDe Jonqui\u00e8re <\/td>\nMartine <\/td>\n33 <\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n

CLIENTS is the “relative” table. If customer n\u00b04, Martine de Jonqui\u00e8re, were to divorce and resume her maiden name (Heras) tomorrow, we would simply modify this information in the “relative” table.<\/p>\n\n\n

Understanding foreign keys<\/a><\/div><\/div>\n\n\n

Table COMMANDES<\/h3>\n\n\n
\n\n\n\n\n<\/colgroup>\n\n\n\n\n\n\n\n\n
Id_Commande <\/th>\nDate_Commande <\/th>\nId_Client <\/th>\n<\/tr>\n<\/thead>\n
1 <\/td>\n11\/04\/2023 <\/td>\n4 <\/td>\n<\/tr>\n
2 <\/td>\n10\/05\/2023 <\/td>\n3 <\/td>\n<\/tr>\n
3 <\/td>\n12\/05\/2023 <\/td>\n4 <\/td>\n<\/tr>\n
4 <\/td>\n26\/05\/2023 <\/td>\n4 <\/td>\n<\/tr>\n
5 <\/td>\n16\/06\/2023 <\/td>\n1 <\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n

In this example, we find the “Customer_ID” column in the ORDERS table (which is the “daughter” table). It points to the “Id_Client” column in the CLIENTS table. In this way, we would know by means of a join that Martine de Jonqui\u00e8res placed three orders: once in April and twice in June.<\/p>\n\n\n

In the CUSTOMERS table, the Customer_ID column is the primary key.<\/p>\n\n\n

In the ORDERS table, the Customer_ID column is the foreign key.<\/p>\n\n\n

Advantages of foreign keys<\/h2>\n\n\n

Referential integrity<\/h3>\n\n\n

The main advantage of using foreign keys is referential integrity: no row in the child table will be complete and valid until a corresponding record exists in the parent table.<\/p>\n\n\n

Consistency of information<\/h3>\n\n\n

All tables referencing the foreign key are guaranteed to produce consistent, up-to-date data. As a reminder, if Martine de Jonqui\u00e8res changes her name, this change will be visible in all tables referencing her identifier.<\/p>\n\n\n

Disadvantages of foreign keys<\/h2>\n\n\n

Reduced processing speed<\/h3>\n\n\n

Of course, the foreign key will mean longer processing times. Each time you insert a new row in a table such as ORDERS, you’ll need to check whether the corresponding customer identifier exists in the CUSTOMERS table.<\/p>\n\n\n

Complexity<\/h3>\n\n\n

Referring to customer_id n\u00b04 may appear more complex than simply indicating the name Martine de Jonqui\u00e8res. And so, a priori, reading a database such as the ORDERS database will not be very explicit at first.<\/p>\n\n\n

Recommended use<\/h2>\n\n\n

Despite the disadvantages of using foreign keys, the use of foreign keys is highly recommended for anyone responsible for designing SQL database management systems. In the long term, it’s a win-win situation. To put it simply, it’s important to use foreign keys whenever you’re dealing with a type of data that is likely to evolve over time. The examples given here clearly illustrate what can be gained. And so, it’s crucial to define foreign keys right from the design stage of an SQL database.<\/p>\n\n\n

\n\n

Related articles<\/p>\n\n\n