Hi Bruno ---

Your situation is ideal for a surrogate. Just a field that holds a unique value, call it PK in your circuit table. Connect the child tables using fkcircuit. What makes your situation ideal is that if you use surrogate keys, you don't have the headache for allowing for circuits where you don't know the ID at the time the order is placed.

>I designed an application which keeps track of configuration of telecommunication circuits (T1 based, ATM based, etc). A table contains the Circuit ID (similar to a serial no, which I use as PK) of each circuit component. Without going into details, other tables contain the orders placed against these circuits, various component specifications and others act as links between the component tables to form the entire logical circuit.

>Since Circuit IDs are determined by the carriers, we don't know what they will be at the time the order is placed. Later, when we receive details on the circuit specifications, we need to update the Circuit ID. Since this Circuit ID may show up in many tables (because of links to other components, order and cost records) I use Referential Integrity to cascade the updates of the PK(Circuit ID) from the main Circuit table to all other related tables.
>
>By doing this, I save a lot of coding and the update is done it one place only.
>
>I wouldn't mind hearing your comments if you disagree with such usage of PKs, but if you do, please comment on why this wouldn't be considered a good practice.