Denormalizing data: store foreign key or not?

When you denormalize, do you store the foreign keys?

The situation is as follows. I have a normalized database that stores a form template that people fill out to report their experience in different skills. The template form will change over time. Phrasing will change, and the number of skills will change. Once submitted, their data will not change.  Users should be able to recreate the form that was originally submitted no matter how much the template may have since changed. Therefore, the system should capture the state of the templates when people submit their reports.

In these sorts of situations, I denormalize the data, storing the template data as well as the responses.

I could leave it normalized and enforce logic that deactivates a template (in whole or part) when it changes, but that is, in my opinion, generally overkill.

My question is, should I store the foreign keys? When I used integer keys (all row ids are surrogate keys), I would have stored them just because integers are cheap and having them might help troubleshoot problems. Now that I’m using GUIDs, I’m less certain the potential benefit is worth the cost.

It’s unlikely the use of the denormalized data in this specific instance will be so intensive that performance is likely to be a problem, but it will grow, it is storing mostly string data (mostly nvarchar). I’m also curious what people think about this.

I’m not completely close-minded, but it’s unlikely I’ll change my mind about using GUIDs and denormalizing. Given that, what’s your opinion on storing foreign keys in denormalized data?



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s