Дебаты о естественных и искусственных ключах так же стары, как и любая реализация базы данных.
Читайте о плюсах и минусах в википедии .
Аргументы в пользу суррогатных ключей легко оспариваются на теоретическом уровне (например, аргумент о том, что с естественными ключами вы рискуете, что ваш PK станет неуникальным, может быть опровергнут ответом - хорошо! Если я столкнусь с такой ситуацией, хорошо, что все сломалось бы вместо наличия искусственно уникальных первичных ключей с дублирующимися записями для фактических данных).
Другим хорошим аргументом является то, что искусственные ключи либо избыточны (в таблице есть еще один уникальный ключ), либо они позволяют вам хранить по существу неуникальные записи.
Тем не менее, найти хорошие естественные ключи иногда бывает так сложно, что вы должны выбрать что-то искусственное и учесть ситуацию, когда у вас будет человек с таким же именем, рожденный в ту же дату (или с неизвестной датой), с другими свойствами xy, которые одинаковы по стоимости.
Кроме того, не очень понятно, что искусственно, а что естественно.
Например, вы можете сказать, что SSN естественен для ваших данных. Хотя это действительно составленное число.
Что касается производительности многоключевых отношений - они не так плохи, как вы могли бы подумать, более того - они сегментируют индексы естественным образом, и с такими ключами вы обычно получаете базу данных, которая действительно хорошо работает с общими запросы без каких-либо дополнительных индексов.
Если вы серьезно относитесь к этим проблемам и если вы пытаетесь построить сложную систему, прочитайте хорошую литературу ( C.J.Date Введение в системы баз данных, в настоящее время в 8-м выпуске приходит на ум)