This is a choice between surrogate and natural primary keys.
IMHO always favour surrogate primary keys. Primary keys shouldn’t have meaning because that meaning can change. Even country names can change and countries can come into existence and disappear, let alone products. Changing primary keys is definitely not advised, which can happen with natural keys.
More on surrogate vs primary keys:
So surrogate keys win right? Well,
let’s review and see if any of the
con’s of natural key’s apply to
surrogate keys:
- Con 1: Primary key size – Surrogate keys generally don’t have problems
with index size since they’re usually
a single column of type int. That’s
about as small as it gets.- Con 2: Foreign key size – They don’t have foreign key or foreign
index size problems either for the
same reason as Con 1.- Con 3: Asthetics – Well, it’s an eye of the beholder type thing, but
they certainly don’t involve writing
as much code as with compound natural
keys.- Con 4 & 5: Optionality & Applicability – Surrogate keys have no
problems with people or things not
wanting to or not being able to
provide the data.- Con 6: Uniqueness – They are 100% guaranteed to be unique. That’s a
relief.- Con 7: Privacy – They have no privacy concerns should an
unscrupulous person obtain them.- Con 8: Accidental Denormalization – You can’t accidentally denormalize
non-business data.- Con 9: Cascading Updates – Surrogate keys don’t change, so no
worries about how to cascade them on
update.- Con 10: Varchar join speed – They’re generally int’s, so they’re generally
as fast to join over as you can get.
And there’s also Surrogate Keys vs Natural Keys for Primary Key?