Это дополнительный вопрос: Являются ли последовательности SQL Server потокобезопасными?
У меня есть две отдельные хранимые процедуры, которые вызывают одну и ту же последовательность. Хранимые процедуры запускаются "параллельно" из пакета SSIS. Между двумя хранимыми процедурами нет никакой синхронизации (кроме того факта, что я гарантирую, что они никогда не будут обновлять одни и те же строки, даже если они обновляют одну и ту же таблицу). При этом нет особой причины, по которой последовательность не может быть вызвана более или менее одновременно двумя хранимыми процедурами. Мой вопрос о том, что именно произойдет в этом случае.
В случае связанного вопроса у OP было несколько приложений-производителей, которые одновременно вставлялись в таблицу, и хотел знать, могут ли они «рассчитывать» на то, что они будут последовательными между процессами (т. Е. Если производитель 2 сначала вызвал последовательность, его ID будет меньше производителя 3). (Это оказалось не так из-за состояния гонки из-за того, что создание идентификаторов и их сохранение были отдельными шагами).
Та же логика, по-видимому, применима и к моему случаю (я не могу рассчитывать на то, что они будут в каком-то конкретном «порядке» из-за того, что я также создаю и храню их на отдельных этапах). В моем случае, однако, меня не особенно волнует, являются ли они последовательными, просто они уникальны.
Могу ли я рассчитывать на то, что это так? Гарантируется ли, что последовательности SQL Server всегда будут создавать уникальные значения (даже если они вызываются более или менее одновременно из разных соединений), или здесь может быть какое-то состояние гонки, из-за которого это больше не так?
Обновлено: один и тот же порядковый номер в конечном итоге может быть добавлен к нескольким строкам, если это имеет значение (хотя он всегда будет добавлен по крайней мере к одной). Я извлекаю число из последовательности, а затем выполняю запрос на обновление, чтобы добавить его в строки, частью которых я хочу, чтобы оно было.
@Damien_The_Unbeliever У меня нет конкретного тестового примера, который предполагает обратное — у меня просто есть приложение, которое требует гарантии того, что это так (потому что я буду использовать число в качестве идентификатора).
Не хотите дубликатов? Принудительно используйте уникальное ограничение.
@SMor Значение из последовательности должно быть уникальным, но значение в таблице не будет уникальным.
@EJoshuaS-ReinstateMonica - «но значение в таблице не будет уникальным». Можете ли вы поместить их в другую таблицу, где они будут уникальными? Похоже, это было бы хорошим решением для твоей паранойи.
Да, есть, и это одна из их самых важных фич, которая описана в документации (выделено мной):
Столбцы идентификаторов можно использовать для создания ключевых значений. Личность свойство столбца гарантирует следующее:
Каждое новое значение генерируется на основе текущего начального значения и приращения.
Каждое новое значение для конкретной транзакции отличается от других одновременные транзакции на столе.
Отказ от ответственности: нет гарантии, что значения являются последовательными.
Это относится и к последовательностям?
Да, это относится и к последовательностям.
Если я правильно понял, вы просто гарантируете, что они уникальны (например, вы хотите, чтобы они были первичным ключом?). Если так, то это правильно. Что касается гарантированного заказа, вы правы, что есть условия, особенно. под нагрузкой они не будут в определенном порядке. Не похоже, что это большая проблема для вас. Пока вы правильно вытягиваете следующее значение, вы в безопасности.
Когда я смотрю на созданные последовательности, я думаю о них как об автонумерации в Oracle, где вы должны получить значение, а затем использовать его, а не IDENTITY в SQL Server (хотя есть способы увеличить IDENTITY, чтобы позже «заполнить дыру»). , поэтому его можно использовать таким же/подобным образом).
Я не исследовал внутренности, но могу предположить, что концепция базовой последовательности используется для IDENTITY под капотом, поскольку идеи по существу те же, за исключением того, что IDENTITY прикрепляется к полю в таблице.
От них не было бы особой пользы, если бы они не производили уникальных значений, но я согласен, что документация по этому поводу немного скудна. Но что мотивирует этот вопрос? У вас есть реальная проблема, симптомы которой заставляют вас подозревать, что это не так? Если это так, возможно, было бы лучше представить симптомы, а не гадать о причине, а затем спрашивать, возможна ли причина.