gardenmanБлин... чтобы узнать Identity-значение нужно обядательно вставить строку в таблицу. (сделать транзакцию) Последнее значение возвратится в @@identity. Чтобы получить значение из последовательности - нужно сделать запрос, который находится все транзакции. Разница - ОГРОМНА!
Огромна для MSSQL. Это уже глобальная тема, на которую нынче принято отвечать "а вот в юконе все будет хорошо". Другой вопрос, что развязывание по времени этих двух событий само по себе может оказаться удобным, если идет какая-нибудь сложная схема со взаимодействием нескольких процессов - мне, правда, такого делать не приходилось.

Другой аспект - секвенсоры позволяют легко и довольно эффективно получить массив будущих id-шников, в то время как @@identity вряд ли столь универсальна.

Alex.CzechСбивается, согласен. Не подумал об этом. Все равно репликацию на GUID-ах делал всегда, когда делал... точнее, в таблице делалось 2 ключа - int identity и плюс еще guid только для репликации
Хм. Согласитесь, эти две задачи удобнее решать одним полем :)

P.S. Не продумал про сбивание. Слишком зашорен - привык, что "текущее значение" хранится и явно запрашивается-изменяется.

tygraХотя я не припомню задач, где бы ID было нужно заранее, а тем более уж сразу несколько заразервировать.
Массовая загрузка данных. Запрос id - довольно дорогая операция, поскольку требует синхронизации на высшем уровне. Соответственно, если сервер занят не только загрузкой, запрашивать по одному номеру на каждую запись - довольно неэффективно.

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

ChA1. SEQUENCE it's cool :), но он не решает проблем с репликацией по большому счету, так как в базе-источнике и базе-приемнике свои значения упомянутого, которые могут также пересекатся, как и identity.
Решает. Я даже написал, как именно. После этого пересечься они могут только в результате "действий руками" - ну а тут и GUID не спасет.

ChA Для репликации в идеале надо получать идентификаторы, практически гарантировано, уникальные вне зависимости от сервера, базы и таблицы.
Совершенно излишние требования. Вы просто подгоняете требования к тому, что есть в MSSQL.

ChA 2. Кстати, до стандарта SQL2003 ни о каких SEQUENCE речи не идет, правда, не идет речи и об identity :) , это к тому, что MS SQL пытается
Хм. Если бы сервера не отрывались от стандартов - мы бы их сейчас ругали совсем не за детали репликации :)

ChAВ частности, мне ни разу не приходилось сталкиваться с потребностью создавать сквозную нумерацию через несколько "разношерстных" таблиц за достаточно немалый срок работы с СУБД, и она кажется несколько "искусственной". Если таковая возможность требовалась, то обычно это было связано с тем, что таковые таблицы по смыслу были подчиненными и связаными с "главной" таблицей, в которой и было поле identity, значения которого мигрировали в ключ "подчиненных" таблиц.
Вы другими словами сказали то же самое - вводить искусственную таблицу с identity. Просто представьте себе, что "главная" таблица не содержит ничего, кроме этого id - ну и, быть может, еще пары атрибутов, типа "создатель" и "дата создания", ради которых не стоит городить таблицу.

Что касается примера - пожалуй, самый "горячий" будет связан с популярным желанием сделать таблички физ-юр лиц со сквозными id - дабы "одним полем id адресовать обе таблицы". Я здесь не имею в виду поднимать тему "насколько это хорошо"; просто наиболее навязшее в зубах.

ChA3. Если в некоторых случаях был необходим признак, гарантировано уникальный и монотонно возрастающий в пределах БД, например, для отслеживания порядка создания записей из разных таблиц, для этого в MS SQL достаточно использовать тип timestamp, который не имеет ровно никакого отношения ко времени, а представляет тупо и монотонно возрастающее binary(8)
Согласен, это вполне удобный для репликации id. По крайней мере пока не пойдет вопрос переполнения :)

ChAЭто ни плохо, ни хорошо, это так.
Хм. А прокомментируете то, что я уже упоминал - если я правильно понимаю, такие манипуляции на триггерах связаны с необходимостью второй раз update-ить ту же запись (и соответственно с дополнительной нагрузкой).

ChA4. Потребность получить заранее значение типа autoincrement, до реальной вставки в таблицу, чтобы затем его использовать, может привести с одной стороны к тому, что разные пользователи могут получить одно и то же значение, что в дальнейшем может привести к конфликту при вставке.
Не может. Наличие такой вероятности автоматом свидетельствует об одной из двух крайне неприятных вещей: либо о возможности получить то же непосредственно при вставке, либо о жесткой синхронизации каждой вставки в таблицу - и тогда о больших базах можно забыть.

ChAС другой стороны, если после каждого чтения значения такого счетчика оно инкрементируется, то возникает опасность быстрого "исчерпания" в случае неверного кодирования, например при "зацикливании".
Хм. В случае неверного кодирования можно получить абсолютно любые результаты - даже верные, если повезет. Не понимаю, что следует из этого аргумента. Реально "теряется" весьма немного id-шников, и, полагаю, если бы они вычислялись при вставке, терялись бы настолько же часто - поскольку основной причиной потери является rollback.

ChAОпять же, если необходимо получить диапазон идентификаторов типа identity, то никто не мешает получить последнее вставленное значение, а затем "сдвинуть" его на нужный шаг, зная, что "пропущенный" промежуток можно использовать позже, но это на любителя и при острой необходимости.
Эта проблема, к сожалению, нормально решается только в Interbase - правда, там свои минусы. Тем не менее, возможность получить id до вставки весьма актуальна - в качестве простого примера можно назвать работу с мастер-деталью с клиента.

andy stвот сижу и думаю, как это у меня работает репликация на identity с разделением диапазонов по серверам? ведь не должна, а работает....
наверное мне только кажется, что у меня mssql, а реально там крутится oracle.
;)
Думаю, реально у Вас крутится решения наподобие предложенного в упомянутой мной статье. Это решение кажется мне.. неоправданно сложным и неудобным - например, с моей точки зрения, диапазоны id вообще не слишком удачная идея.