Foreign Keys and Primary Keys are the perfect partners. You can think of them as the leads in your favorite buddy cop flick.
They’re both extremely different but in ways that wind up complementing each other, helping them to eventually foil the bad guys and save the day. But, instead of bad guys, Keys foil redundant data and empty table space!
This tension between Foreign and Primary keys is what makes them effective database tools, but are there any instances in which a Foreign Key can be either Foreign or Primary? Is such a thing even possible? Well, let’s discuss the matter in more detail and find it!
What Are Foreign And Primary Keys?
Put simply, Keys are tools used to link two tables together inside a database. The Foreign Key is the field in a (child) table that references a field in a (parent) table. The referenced field is known as the Primary Key.
These links are established for two core reasons:
To Save Space
Database objects (tables, indexes, etc) need to be as intuitive and efficient as possible, which means that redundant data needs to be kept to a minimum. Splitting data across two tables and linking them with Keys is a great way to do so.
To Reduce Human Error During Data Queries And Manual Scanning
Duplicate data in a single table can lead to human error during processing. For example, let’s say that we owned an online store, and to keep track of orders, we created a table called tblOrders that contains the following columns: Customer Name, Customer Address, Order ID, and Order.
If one of our customers keeps coming back to our store and placing orders, our table will be gathering the same name and address over and over again, which is confusing for our dispatch manager to deal with.
Splitting the data into two tables and linking them with Keys eliminates these redundancies.
What Seems To Be The Problem With A Hybrid Foreign/Primary Key?
The seemingly gaping flaw in our idea of a Key that can be either Foreign or Primary is that they’re fundamentally different.
The golden rule of Foreign Keys is that the field is not unique; it can display duplicate information, while the golden rule of Primary Keys is that they are unique, and cannot display duplicate information.
So, if these Keys are completely contradictory in nature, how in the heck can a single field be either the Foreign or Primary Key? It just doesn’t seem to make any sense, but that doesn’t necessarily mean it’s not possible.
It’s All About Relation Type
Okay, so we’ve established that the role of Foreign and Primary Keys is to form a relationship between two fields in a database, but here’s the thing… the relationships between tables aren’t always the same.
There are three types of table relationship in total:
An individual record in one table is related to an individual record in another table.
For example, a school’s student record might be composed of two tables, one called Students, and one called StdContact Details. Both tables would contain the field, Student ID, which would be linked to one another using Keys. As this relationship has no bearing on any other field outside the two that are linked, it’s considered a one-to-one relationship.
An individual record in one table is related to multiple records in another table.
The link between the customer table and order table of a shop is the perfect example of a one-to-many relationship, as there can only be one customer per order, but there can be any number of orders.
Multiple records in one table are linked to multiple records in another table.
An example of a many-to-many relationship would be two tables in a university database linking students to their chosen classes, as students can choose many classes, and classes have many students.
However, technically speaking, many-to-many relationships are problematic in databases. Instead, a third object called a joining table will be created to sit between the two existing tables.
Each of the original tables will then share a one-to-many relationship with the central joining table instead of a many-to-many relationship with each other.
Only one of these relationship types is capable of supporting hybrid keys that can be both Foreign or Primary. Any guesses which?
The answer is… (drumroll, please)… one-to-one relationships!
Yep, one-to-one relationships are the only instance in database structure where the Foreign Key can also be the Primary Key.
Now, bear in mind that when I say this, I don’t mean that a Foreign Key can also be a Primary Key at the same time, just that it doesn’t matter which of your two tables holds the Foreign or Primary Key.
In a one-to-many relationship between tables, there is always a reference key and a referenced key, telling you which table has to hold the Foreign Key and which has to hold the Primary Key — you don’t get the choice.
A many-to-many relationship requires that third table, which has to harbor the corresponding Foreign Key to the two main tables’ Primary Keys — again, you don’t have a say in the matter.
With a one-to-one relationship, on the other hand, each field is equally referenced and referencing, so it doesn’t matter how you allocate roles of Foreign and Primary Key between them. Switch them around all you want, and it won’t affect the way the data behaves within the tables.
Well, we finally got down to the bottom of it — A Foreign Key can indeed be a Primary Key, but only in a very specific circumstance, and that’s a one-to-one relationship between two tables. The question is… is it worth using a one-to-one pairing in the first place? Well… It all comes down to preference.
Certain database designers feel that breaking a single table into two separate entities is inelegant, while others believe that it’s much better to have two optimized tables than one table with lots of blank spaces. So, which do you prefer?