I am looking more and more at ROWGUIDs for my surrogate PKs, but I am not sure about the performance implications, compared to integer PKs.

>Erik,
>
>I've got a good one on this. How about this for a nightmare waiting to happen?
>
>As you know, I work for Shaw Industries, the largest manufacturer of broadloom carpet in the world. I've written over a dozen systems designed to monitor the efficiency of the manufacturing process. One of the principle processes, and one that applies to every order, is called tufting. Tufting is the process of sewing the yarn into the primary backing. Having a primary key in this instance is a necessity since the data is being stored on SQL Server.
>
>Now each plant enters the production information daily and, usually runs three shifts. So at minimum the natural key would be date and shift. That's not enough, however.
>
>Each plant has multiple tufting machines which are numbered. OK, so that would give us date, shift, and machine. Nope, that won't do it either. A given machine can run more than one order on a shift, so this won't uniquely indentify the record.
>
>Each machine can run more than one style of carpet. So this would give us: Date, shift, machine number and style. Naw...that won't work either. At a plant it is possible, during the course of a shift for multiple orders of the same style.
>
>So this would give us, at least, date, shift, machine, style, and order as the absolute minimum for the primary key based on the data. That's five different fields.
>
>As a result, I decided that an indentity column was the answer. Natural keys, anyone?