>My question is of normalization:
>
>If I have an Invoices table which is related to a Clients table, is it
>proper to store the Client's name in the invoice table, or the primary
>key from the Client table?
>
>I'v always beleived in storing the primary key. The problem is, you can
>then no longer delete the client record, because you would have a dangling
>reference in the Invoice table.
>
>If you store the client's name, you can at any time remove the client record
>and still know who the invoice was for, but if the client's name changes, you
>have to go through all table and change the name.
>
>Anyone have any thoughts on this?
>
>Thanks

Kevin,
It really depends on what the information in the invoices table is supposed to represent.

If it simply a link to the client's table, then you would, IMO, store the client's PK. If you attempt to delete a client, referential integroity rules would take effect.

You could decide to not delete the client if they had invoices. - Restrict
You could decide to delete the invoices associated with that client. - Cascade
You could decide to set the invoice's FK to NULL or some DEFAULT value.

However, if the information is to actually show some type of history then you should store the name. In this case, the invoice table is not really related in the database sense. It is associated (my word) because the source of the information comes from the client table and once in the invoice table, you can't go back. This is good for names, addresses, prices of items, etc. that can and might change but you need to know the values that existed in the past when it occurred.

HTH.