Зачастую использование суррогатных ключей, из которых столбцы IDENTITY являются наиболее распространенными, делается из соображений производительности. Вы все равно должны определить естественные ключи (столбцы, которые делают строку уникальной на основе данных).
Обычно суррогатные ключи являются целочисленными значениями. Это позволяет легко связывать их друг с другом, используя соединения с другими таблицами (и соответственно ограничивать с помощью внешних ключей). Кроме того, когда речь идет о SQL Server, все некластеризованные индексы зависят от кластеризованного индекса. Таким образом, если кластерный индекс основан на естественном ключе и в результате имеет большой размер, тогда все некластеризованные индексы также будут большими, поскольку они будут ссылаться на кластерный индекс. Поэтому многие люди строят первичный ключ на основе этого целочисленного суррогатного ключа. Я знаю, что немного упрощаю, но это ключевая причина для использования суррогатных ключей.
Недостаток в том, что суррогатный ключ фактически бессмысленен. Если бы кто-то изменил значение ключа, вы могли бы разорвать связь, если ограничения внешнего ключа отсутствуют или отключены. В случае внесения изменения, которое изменяет альтернативный ключ, вы фактически изменяете сами данные. Таким образом, вы ожидаете такой разрыв, если сущности построены правильно, и вы также изменили бы данные в связанных таблицах.