Гарантируется ли, что последовательности SQL Server всегда генерируют уникальные значения, даже если они вызываются одновременно из нескольких подключений?

Это дополнительный вопрос: Являются ли последовательности SQL Server потокобезопасными?

У меня есть две отдельные хранимые процедуры, которые вызывают одну и ту же последовательность. Хранимые процедуры запускаются "параллельно" из пакета SSIS. Между двумя хранимыми процедурами нет никакой синхронизации (кроме того факта, что я гарантирую, что они никогда не будут обновлять одни и те же строки, даже если они обновляют одну и ту же таблицу). При этом нет особой причины, по которой последовательность не может быть вызвана более или менее одновременно двумя хранимыми процедурами. Мой вопрос о том, что именно произойдет в этом случае.

В случае связанного вопроса у OP было несколько приложений-производителей, которые одновременно вставлялись в таблицу, и хотел знать, могут ли они «рассчитывать» на то, что они будут последовательными между процессами (т. Е. Если производитель 2 сначала вызвал последовательность, его ID будет меньше производителя 3). (Это оказалось не так из-за состояния гонки из-за того, что создание идентификаторов и их сохранение были отдельными шагами).

Та же логика, по-видимому, применима и к моему случаю (я не могу рассчитывать на то, что они будут в каком-то конкретном «порядке» из-за того, что я также создаю и храню их на отдельных этапах). В моем случае, однако, меня не особенно волнует, являются ли они последовательными, просто они уникальны.

Могу ли я рассчитывать на то, что это так? Гарантируется ли, что последовательности SQL Server всегда будут создавать уникальные значения (даже если они вызываются более или менее одновременно из разных соединений), или здесь может быть какое-то состояние гонки, из-за которого это больше не так?

Обновлено: один и тот же порядковый номер в конечном итоге может быть добавлен к нескольким строкам, если это имеет значение (хотя он всегда будет добавлен по крайней мере к одной). Я извлекаю число из последовательности, а затем выполняю запрос на обновление, чтобы добавить его в строки, частью которых я хочу, чтобы оно было.

От них не было бы особой пользы, если бы они не производили уникальных значений, но я согласен, что документация по этому поводу немного скудна. Но что мотивирует этот вопрос? У вас есть реальная проблема, симптомы которой заставляют вас подозревать, что это не так? Если это так, возможно, было бы лучше представить симптомы, а не гадать о причине, а затем спрашивать, возможна ли причина.

Damien_The_Unbeliever 09.12.2020 16:41

@Damien_The_Unbeliever У меня нет конкретного тестового примера, который предполагает обратное — у меня просто есть приложение, которое требует гарантии того, что это так (потому что я буду использовать число в качестве идентификатора).

EJoshuaS - Stand with Ukraine 09.12.2020 17:05

Не хотите дубликатов? Принудительно используйте уникальное ограничение.

SMor 09.12.2020 17:23

@SMor Значение из последовательности должно быть уникальным, но значение в таблице не будет уникальным.

EJoshuaS - Stand with Ukraine 09.12.2020 17:25

@EJoshuaS-ReinstateMonica - «но значение в таблице не будет уникальным». Можете ли вы поместить их в другую таблицу, где они будут уникальными? Похоже, это было бы хорошим решением для твоей паранойи.

Ben Thul 09.12.2020 23:20
ReactJs | Supabase | Добавление данных в базу данных
ReactJs | Supabase | Добавление данных в базу данных
Это и есть ваш редактор таблиц в supabase.👇
Понимание Python и переход к SQL
Понимание Python и переход к SQL
Перед нами лабораторная работа по BloodOath:
2
5
492
2
Перейти к ответу Данный вопрос помечен как решенный

Ответы 2

Да, есть, и это одна из их самых важных фич, которая описана в документации (выделено мной):

Столбцы идентификаторов можно использовать для создания ключевых значений. Личность свойство столбца гарантирует следующее:

  • Каждое новое значение генерируется на основе текущего начального значения и приращения.

  • Каждое новое значение для конкретной транзакции отличается от других одновременные транзакции на столе.

Отказ от ответственности: нет гарантии, что значения являются последовательными.

Это относится и к последовательностям?

EJoshuaS - Stand with Ukraine 09.12.2020 16:33

Да, это относится и к последовательностям.

Gordon Linoff 09.12.2020 16:52
Ответ принят как подходящий

Если я правильно понял, вы просто гарантируете, что они уникальны (например, вы хотите, чтобы они были первичным ключом?). Если так, то это правильно. Что касается гарантированного заказа, вы правы, что есть условия, особенно. под нагрузкой они не будут в определенном порядке. Не похоже, что это большая проблема для вас. Пока вы правильно вытягиваете следующее значение, вы в безопасности.

Когда я смотрю на созданные последовательности, я думаю о них как об автонумерации в Oracle, где вы должны получить значение, а затем использовать его, а не IDENTITY в SQL Server (хотя есть способы увеличить IDENTITY, чтобы позже «заполнить дыру»). , поэтому его можно использовать таким же/подобным образом).

Я не исследовал внутренности, но могу предположить, что концепция базовой последовательности используется для IDENTITY под капотом, поскольку идеи по существу те же, за исключением того, что IDENTITY прикрепляется к полю в таблице.

Другие вопросы по теме