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

Можете на примере - может быть, я неправильно Вас понял?

andy stодин публикатор, остальные подписчики,
Честно говоря, уже неинтересно :)

andy stдля каждого сервера задан свой диапазон identity для этой таблицы.
т.е. на подписчике 1 - 999999, на втором сервере 1000000 - 1999999 и т.п.
(т.е. так определяются "откуда растут ноги у записей").
И? Как только автоматически выделится следующий диапазон - откуда Вы узнаете, какому серверу он принадлежит? Или будете помнить, что "первый миллион - первый сервер, второй - второй, третий миллион - снова второй, четвертый миллион - первый, пятый миллион - третий..." И так, я полагаю, помнить по каждой таблице? У меня их, знаете ли, реплицировалось порядка тысячи двухсот; память кончится.

andy st
по поводу надолго отрезан - прецедентов пока не было. но диапазон выбирался из расчета работы диапазона примерно года на 3-4. за такое время линию связи уж точно восстановят. ;)
Хм. Знаете, возможности сервера на таких объемах как-то неловко обсуждать :) Полагаю, с миллионом записей за три-четыре года и парадокс справится без особых проблем.

А вот через четыре года - давайте Вы нам расскажете, так ли удобно определять, "откуда ноги растут".

ChA softwarerпока не пойдет вопрос переполнения :)Хммм... Переполнение при 2 ⁶⁴ ? Теоретически - да, а если реально смотреть на жизнь ?
Там не зря стоит смайлик. Но если учесть, что у меня ожидаемый прирост базы порядка 2^32 записей в год - для "пересчета по каждому чиху" число не кажется таким уж фантастическим.

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

ChAСмысл в чем ? Если это разные сущности, то зачем они разделяют одну и ту же последовательность ? Пусть каждая имеет свою.
Смысл в том, что последовательности могут применяться не только для суррогатных ключей, но и для нумерации документов. И бухгалтер вполне может сказать - и говорит на практике - "хочу, чтобы все типы накладных имели сквозную нумерацию". Поскольку это несложно сделать - разумно пойти ему навстречу. Ну а то, что "все накладные" запросто могут не иметь предка - исключая разве что "самого общего" - полагаю, очевидно.

ChAНа примере Ю и Ф лиц: если по бизнес-логике в БД может существовать таблица, в которой определенное поле может ссылатся на обе таблицы, то сделать ссылочное ограничение на обе таблицы одновременно все равно нельзя, так зачем огород в виде разделяемой последовательности городить ?
Огород в виде разделяемой последовательности позволяет не делать поля наподобие "тип записи, на которую ссылается данное поле". Пример звучал здесь же совсем недавно - CONTRACTORS JOIN PHPERSONS дает всех контрагентов-физиков, CONTRACTORS JOIN ORGS дает всех контрагентов-юриков.

Лично мне такой подход не нравится. Но он существует, достаточно часто упоминается и, собственно, при многочисленных категориях адресатов становится менее невыгодным, чем другие варианты.

ChA
softwarerВы просто подгоняете требования к тому, что есть в MSSQLНикак нет, насколько помню для каких-то видов репликации, кажется MERGE, именно это и нужно, но так как не использую, то не готов защищать эту точку зрения.
Сказать по правде, я не знаю, что такое MERGE репликация, но почти уверен, что это термин откуда-то из MSSQL. Во всяком случае, адекватная репликация спокойно делается при куда более слабых требованиях.

ChA
P.S. Не пытаюсь защитить MS SQL или противопоставить его Oracle, все что хотелось бы сказать: одни и те же задачи можно решать разными способами, и сравнение в однозначное превосходство одного из них далеко не всегда оправдано.
Можно решать разными способами. Если Вы посмотрите подборку моих писем - я не склонен кричать "лучше всегда и везде". Собственно, когда мне говорят "а вот здесь не лучше" - я даже чаще верю на слово, нежели лезу проверять.

Что касается секвенсоров - они с одной стороны не имеют явных собственных недостатков, а с другой позволяют "одним движением" решить задачи, каждую из которых можно решать большими или меньшими усилиями "другими методами". То есть: да, можно раздать диапазоны. И на небольших базах это сработает. Да, можно не забыть при создании каждого поля добавлять "not for replication" - хотя это уже плохое, неудобное требование. Можно сделать GUID и плевать на его большой размер. Но вопрос: зачем? То, что позволяет одной строкой обойтись без всего этого, по-моему, таки "лучше".

andy stа я помнить и не буду. мне это надо, чтобы в реальном времени разруливать проблемы, не более.
Допустим - хотя уже весьма сомнительно. Итак, для скольких таблиц и скольких серверов Вы обещаете помнить текущие диапазоны?

andy st;) давайте еще пиписьками померяемся.
Зачем? Вы сначала сказали - у Вас работает, а потом оказывается, что работает в совершенно нерепрезентативных условиях. То есть - я совершенно уверен, что MSSQL способен на куда большее.

Соответственно, Ваше утверждение становится примерно таким: MSSQL крут, поскольку приемлимо решает копеечную задачу. Лично у меня о нем лучшее мнение.