Вообще говоря, автоинкрементная клавиша не будет сталкиваться; на самом деле, я не уверен, как это сделать (поскольку большинство определений в SQL включают ограничение Unique). Однако вы можете получить duplicate key ошибок. Почему вы позволяете внешним поставщикам определять, какие у вас внутренние ключи? Примите законченную запись от них и сгенерируйте ключи самостоятельно. Если у вас заканчиваются ключи, увеличьте размер столбца (до длинного). Да, вы можете создать новый столбец GUID, но, скорее всего, вы все равно будете генерировать GUID, так в чем же разница?
Часто большинство таблиц в базе данных имеют более одного «уникального» ключа. Это «естественные» ключи - фактические столбцы, которые составляют уникальный набор данных; к сожалению, это может в конечном итоге составить всю ширину таблицы (именно поэтому используются id столбцы). Кроме того, если не существует какого-то странного варианта использования, не сообщайте серверу об идентификаторах клиента - информируйте клиентов об идентификаторах сервера и отслеживайте их в отдельном столбце (при необходимости) на клиенте. Затем может иметь свои собственные внутренние идентификаторы, которые они используют перед загрузкой, которые не имеют отношения к ключам, которые вы возвращаете, и которые они никогда не передают на сервер.
Не имеет значения, какой у сервера идентификатор (int или GUID), хотя я бы рекомендовал придерживаться того, что у вас есть. Всякий раз, когда клиент дает вам строку для размещения на сервере, возвращайте ему сгенерированный идентификатор с сервера. Это препятствует тому, чтобы клиенты пытались вставить уже используемые идентификаторы, и связанные с этим проблемы (откуда вы знаете, что полученный вами идентификатор не должен был быть сгенерирован каким-либо другим устройством?). Я бы сказал, что клиенты не могут диктовать внутренние идентификаторы на сервере
EDIT:
В свете некоторых быстрых исследований репликации (в ответ на HLGEM) и перечитывания исходного вопроса; Первоначально я принял этот вопрос как вопрос о том, чтобы позволить клиентам диктовать внутренние первичные ключи (что все еще плохо) и / или заменить первичные ключи int на GUID. Хотя ваши точные потребности могут не потребоваться, добавление дополнительного столбца GUID, который может заполнить клиент, будет работать. Некоторые рекомендации:
1) Рассматривать нарушения уникального ключа (случайные или злонамеренные) в столбце GUID как исключение business , а не как исключение system . Я бы, вероятно, рекомендовал сообщить клиенту, что нужно заново сгенерировать GUID и повторно отправить (без вывода сообщений).
2) Клиент никогда не может определять точные значения столбцов первичного ключа в базе данных. Фактически, если вы используете столбец GUID, клиенту может даже не понадобиться знать о них.