Since the title might be considered a bit vague, I don’t want you to wade through the article to figure it out. I will spare you the typical clickbait introduction, with me telling you what a foreign key constraint is, and why it and all the other constraint types provided by relational engines are useful. I will get straight to the point first: One more reason to use them is that they are very helpful when using a large language model AI (LLM), like Microsoft Copilot, currently in preview for Azure SQL.

If you are a relational database programmer, you have hopefully heard about foreign keys. They let you set up a relationship between one set of columns, to another set of columns. For example, if you have an invoice table with a customerId and a customer table with a primary key of customerId, a foreign key can establish a relationship between these two columns.

Since the primary topic of this discussion is the benefits for AI of using foreign key constraints, let’s ignore all the other values of foreign key constraints. The fact that they help the integrity of your data, can be useful in query optimization, and are at the very least, awesome documentation, let’s just ignore all of that and say none of that matters at all.

If you ask an LLM to join our hypothetical invoice table to an equally hypothetical customer table, the likely shared column of customerId would certainly be recognized as a likely way to join the two table. But what if your table has other shared column names. RowCreatedTime, Name, etc. How would it know that these too weren’t keys that needed to be joined on? It wouldn’t. And since there is a very common practice of naming the surrogate key ID in every table? It is not possible to have two ID columns in the same table. So, we typically end up with Invoice.CustomerId joining to Customer.Id.

But let’s be clear, not every table has even that level of clearly named columns. Let’s take a rather silly example of a couple of tables named T1 and T2. Their key columns are T11 and T21. In T11, there is a column T25 that references T11. Now, I did say this naming standard was silly, but this absolutely happens. And not always in as orderly a fashion as this. Sometimes table and column names may actually be something as “interesting” as a GUID (not the values, but the actual tables and columns). If you need to join T1 to T2, without a foreign key, you will 100% need to know the structure… and no LLM will likely ever be able to figure that out with any regularity. Certainly not in the amount of time you have hoped.

But if you have that foreign key in place… not only will your LLM be able to write T2 JOIN T1 on T2.T25 = T11; your programmers won’t be able to mess up your data and forget to only put values into T25 that exist in T11. Which is quite a feat because it was really hard just typing this and only needing to remember two awful column names. So don't forsake the wonderfully powerful foreign key constraint, if for no other reason than the joy of letting AI do some of the dirty work of joining tables for you in the future!