I am struggling with the philosophical discussions about whether or not to use composite primary keys on my SQL Server database. I have always used the surrogate keys in the past and I am challenging myself by leaving my comfort zone to try something different. I have read many discussion but can’t come to any kind of solution yet. The struggle I am having is when I have to update a record with the composite PK.
For example, the record in questions is like this:
ContactID, RoleID, EffectiveDate, TerminationDT
The PK in this case is the (ContactID, RoleID, EffectiveDate). TerminationDT can be null.
If in my UI, the user changes the RoleID and then I need to update the record. Using the surrogate key I can do an Update Table Set RoleID = 1 WHERE surrogateID = Z. However, using the Composite Key way, once one of the fields in the composite key changes I have no way to reference the old record to update it without now maintaining somewhere in the UI a reference to the old values.
I do not bind datasources in my UI. I open a connection, get the data and store it in a bucket, then close the connection. What are everyone’s opinions? Thanks.
What you’re saying by referencing ideas like “the old record” is that the relationship has a semantic meaning independent of the composite key elements. The very fact that you NEED a key to refer to the old record means that the composite key elements are not sufficient. You still maintain foreign keys, of course, but it seems pretty clear to me that you need a primary key here, and it’s not a surrogate key in the usual sense.
Use the surrogate key guilt-free, in my opinion.