Существует несколько устаревший подход в проектировании БД, иногда ошибочно называемый "академическим", когда первичный ключ отношения выбирается как один из естественных ключей отношения. Обычно таким ключом становится имя записи.
В приведенном вами вопросе именно такой подход и используется. Но этот подход устарел по многим причинам. Первая: первичный ключ записи - это то, что используется для ссылок на запись как в самой БД, так и за ее пределами. Желательно делать его как можно меньше - все же большинство естественных ключей строковые.
Причина вторая - многие вещи, выглядящие на первый взгляд как естественные ключи, на самом деле не являются такими. К примеру, среди людей бывают полные тезки (да еще и родившиеся в один день). В магазине может быть два товара с одним и тем же названием в разных отделах...
Причина третья - естественный ключ еще и может изменяться, что так же ведет к проблемам. Так, для человека естественным ключом мог бы быть номер паспорта или свидетельства о рождении - но эти документы могут быть заменены при достижении определенного возраста или в случае утери.
Поэтому хорошей практикой является введение суррогатного ключа - это новое поле, не имеющее никакого отношения к предметной области. Обычно его тип - автоинкрементное 32х-разрядное целое, реже - 64х-разрядное. Еще это может быть UUID.
Как правило, при наличии такого поля нет никакого смысла в составных ключах.
Тем не менее, иногда составные ключи бывают полезны. Вот эти случаи:
Таблицы-связки для отношений "много ко многим". Обычно такие таблицы создаются и управляются библиотеками ORM самостоятельно - но иногда приходится создавать их отдельно. В таких таблицах естественным ключом является вся запись целиком - и нет никаких причин создавать отдельный суррогатный ключ.
Некоторые дочерние подобъекты, не имеющие смысла в отрыве от родительского. Если мы делаем систему для тестирования учащихся - то иногда имеет смысл обращаться к ответу на вопрос как к 5му ответу на 147й вопрос - а не к 3423му ответу вообще. А иногда наоборот.
Использование отношений в БД для дополнительной проверки целостности. Существует так называемая доменно-ключевая нормальная форма, в которой любые ограничения на данные реализуются в формате внешних ключей. В таком случае иногда имеет смысл включать дополнительные поля в первичный ключ.