Deciding between an artificial primary key and a natural key for a Products table

Question

Basically, I will need to combine product data from multiple vendors into a single database (it\'s more complex than that, of course) which has several tables that will need

Answer 1

The ever present danger with natural keys is that either your initial assumptions will be proven wrong now or in the future when some change is made outside your control, or at some place you'll need to reference a record where passing a meaningful field is not desired (ex. a web application that uses an employee's social security number as the primary key, and then has to use urls like /employee.php?ssn=xxxxxxx)

From my own personal experience with "unique" SKU's and vendor data feeds - are you absolutely sure they are sending you a feed with complete, unique, well formed SKUs?

I've had to personally deal with all of the following when getting feeds from vendors who have varying levels of IT and clerical competence:

• Products are missing their SKU entirely ("")
• Clerks have used placeholder SKUs in their database like 999999999 and 00000000 and never corrected them
• Those doing the data entry or importation have confused between various product numbers, mixing up things like UPC with SCC, or even finding ways to mangle them together (I've seen SCC codes with impossible check digits at the end, because they just copied the UPC and added 01 or 10, without correcting the check digit)
• For special reasons, or just incompetence, the vendor has entered the same product twice in their database (for example rev. 1 and rev. 2 of the same motherboard have the same SKU, but exist as 2 records in the vendors database and data feed because rev 2. has new features)