Первичные ключи должны быть уникальными, существовать во время создания строки и быть как можно более неизменными. ИМО, дискуссии о том, использовать ли суррогатный ключ, должны быть вторичными по отношению к вопросам целостности данных.
Если, например, на товаре был отмечен серийный номер, который должен был существовать на момент ввода строки в базу данных, и гарантированно был уникальным, то IMO, который сделал бы хороший первичный ключ. Причина в том, что это значение будет использоваться в качестве внешнего ключа в других таблицах, и это сэкономит вам затраты на дополнительный поиск для получения серийного номера продукта. Дополнительное пространство для хранения несущественно, пока вы не попадете во многие миллионы строк. Однако, если серийный номер был проштампован каким-либо другим производителем, поэтому у вас не было гарантий уникальности («это, вероятно, уникально» недостаточно), тогда суррогат подходит. На самом деле, я бы сказал, что хорошая часть, если не в большинстве таблиц «продукты» используются суррогатные ключи, потому что никакое значение, которое гарантированно будет доступно во время входа, гарантированно будет уникальным и будет относительно неизменным, не доступно, так как ключ.
Однако , многие разработчики, использующие суррогатные ключи, упускают из виду необходимость того, чтобы каждая таблица, имеющая суррогатный ключ, должна также иметь другой ключ (т.е. уникальное ограничение ). Таким образом, в вашем случае с продуктами, даже если вы добавите целочисленный первичный ключ, у вас все равно должно быть уникальное ограничение на имя продукта. Уникальное ограничение на имя продукта создает то, что называется ключом-кандидатом, а целочисленное значение является первичным ключом.
Суррогатные ключи должны быть закулисными. В то время как целочисленные ключи работают лучше всего и их легко создавать, у них есть один недостаток: разработчикам приложений легко, даже соблазнительно показать значение ключа пользователям. Это ошибка ИМО. Пользователи никогда не должны видеть значение ключа, иначе они будут полагаться на само значение, которое создает проблемы, если вам нужно повторно упорядочить значения (например, с помощью слияния базы данных) или если вы используете значения, созданные в промежутках, созданных Значение идентичности, и они полагаются на значения, являющиеся последовательными. Если вы никогда не показываете это значение пользователям, использование целого числа PK - это нормально.