Question

This is more of a design problem then a programming one.

I have a table where I store details about retail products:

Name    Barcode    BarcodeFormat  etc...
---------------------------------------- 

(Name, Barcode, BarcodeFormat) are three columns will uniquely identify a record in the table (Candidate Key). However, I have other tables that need a FK on this one. So I introduced an auto_increment column itemId and made that the PK.

My question is – should I have the PK as (itemId, Name, Barcode, BarcodeFormat) or would it be better to have PK(itemId) and UNIQUE(Name, Barcode, BarcodeFormat).

My primary concern is performance in terms of INSERT and SELECT operations but comments on size are also welcome.

I’m using an innodb table with mysql

Answer 1

Definitely: PK(itemId) and UNIQUE(Name, Barcode, BarcodeFormat).

• You don’t want the hassle of using a multi-part key for all your joins etc
• You may one day have rows without barcode values which then won’t be unique, so you don’t want uniqueness hard-wired into your model (you can easily drop the unique without breaking any relationships etc)
• The constraint on uniqueness is a business-level issue, not a database entity one: You’ll always need a key, but you may not always need the business rule of uniqueness