May 23, 2012

So I’ve been working on an automation project that makes frequent use of foreign key metadata. I find myself writing queries for this data but I discovered that there’s no super-easy out-of-the-box view of foreign keys for me to use. Here are the ones I considered.

INFORMATION_SCHEMA views

INFORMATION_SCHEMA views that give me foreign key information include

INFORMATION_SCHEMA.CONSTRAINT_COLUMN_USAGE for the foreign key info

INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS for the referring columns,

INFORMATION_SCHEMA.CONSTRAINT_COLUMN_USAGE for the referenced columns

The first view here gives a list of foreign keys and you have to join to the other two tables in order to find the column names. But it’s a crummy solution. First of all, if the foreign key has multiple columns, there’s no real way to match the referring columns to the referenced columns.

Microsoft SQL Server system views

These are the views I deserve, but not the views I need right now. The joins are just too annoying to remember and type each time.

Besides, the word “parent” used here changes with context. The parent table in a foreign key relationship owns the foreign key and does the pointing. But say I’m modeling a hierarchy. In the context of the data model, children records point to their parent records. The mental effort needed to keep these straight is not difficult, but it’s annoying.

My Own Views

So I’ve created my own, the goal is to simplify typing and minimize joins. I skip the word “parent” all together and use “referrer” and “referrenced”. Feel free to use and build on these.

Update June 7, 2012: I added columns ReferrerColumnCanBeNull to each view. I found I wanted it, so I added it here.

Bummer! The foreign key information can be used for some very interesting purposes. I have used it for generating SQL code to do the same thing as Red Gate’s SQL Data Compare. You can execute the generated SQL code over and over, without having to go through the GUI over and over. I have also used it for generating SQL code to manipulate a set of related rows in related tables, as a unit. The generated SQL code can have an effect like ON DELETE CASCADE, but it can also do things like copying a set of related rows from related tables into a demo database.

The lack of a good way to get the foreign keys always baffles me. We will have issues if the ability to roll your own views is hampered by underlying system changes. The upside is all the other nice things you’re able to infer fron tge schema information.

It seems like many people are interested in foreign key metadata. How about sharing some ideas for how it’s used? I use it for a lot of SQL code generation and I gave a couple suggestions (see above). What are others doing with it?

Generating SQL code is my own most recent use. Specifically, I have the task of deleting a large portion of a database in batches without being able to (or not wanting to) rely on referential actions like “ON CASCADE DELETE”. It sounds a bit like your project DBAdmin. I hope that makes some sense.

Michael
A nice article, I also find FK are not being used effectively as well as the other constraints..
FYI – I’m doing a virtual session on “Constraints” including FK pretty soon {19th June 2012} for the DataArch Virtual Chapter details @ DataArch.sqlpass.org