Да, и есть аргумент, что это на самом деле "лучше", чем первичный ключ, так как правило, что столбец первичного ключа не обнуляем, во многих отношениях является искусственным ограничением.
Если вы сделаете его UNIQUE CLUSTERED INDEX, тогда вы получите почти все, что первичный ключ приносит в таблицу, кроме нежелательного правила, согласно которому столбцы не должны иметь значение NULL. Однако они все равно должны быть уникальными, поэтому у вас может быть только одна строка, где все пять столбцов в вашем индексе, например, равны нулю.
Таким образом, вы можете использовать свой индекс при создании ограничений внешнего ключа, вы будете гарантировать, что данные заказа сохранены, и каждая строка должна быть уникальной. Тем не менее, индекс, вероятно, не будет невероятно полезным для запросов, и, поскольку он будет широким, и вы сказали, что есть много удалений / вставок, он будет иметь тенденцию фрагментировать ваши данные.
Лично мне хотелось бы сделать это уникальным ограничением, но не кластеризованным. Затем он выполнит работу по предотвращению создания неуникальных данных.
Затем вы можете добавить суррогатный ключ и сделать его первичным ключом. Я сомневаюсь, что вы когда-нибудь «исчерпаете» (или «переполните»?) Число делающих это.
Так зачем мне использовать суррогатный ключ?
Ваш суррогатный ключ будет намного уже, поэтому меньше воздействия фрагментации из-за большого количества вставок / обновлений / удалений.
Тогда полезно, если вам нужно расширить базу данных. Скажем, у вас есть только одна таблица, и она всегда будет единственной таблицей во всей базе данных. В этом одном сценарии было бы разумно не беспокоиться о суррогатном ключе. Это не дает вам никакой ценности; это просто ненужные накладные расходы.
Однако давайте предположим, что у вас есть другие таблицы, висящие над вашей "основной" таблицей (таблица с 5 столбцами, образующими уникальный ключ). Добавление суррогатного ключа позволяет вам создавать любые дочерние таблицы с одним идентификатором, который ссылается на родительскую таблицу. Альтернативой может быть принудительное добавление ВСЕХ пяти столбцов, образующих уникальный (кандидатский) ключ каждый раз, когда вы создаете дочернюю таблицу.
Теперь у вас есть узкий кластерный индекс, который фактически служит цели, и фрагментация будет не такой плохой, как с пятью столбцами.