SQL Server Transactional Replication и различные первичные ключи

Question

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

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

Answer 1

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

Вы можете попробовать приостановить репликацию, а затем попробовать отказаться от ограничения первичного ключа, воссоздать его как некластеризованный ПК, а затем не приостанавливать репликацию. Если SQL Server не позволит вам отказаться от ПК, вы узнаете, прежде чем наносить урон.

Альтернативой является прерывание репликации и повторная инициализация.

В любом случае, вы захотите внести изменения во время обслуживания.

Answer 2

Непосредственно, для первичного ключа его невозможно. Другой способ: когда вы устанавливаете транзакционную репликацию, когда вы выбираете статьи для репликации, вы можете выбрать различные свойства, такие как «проверка ограничения внешнего ключа». Установите для этого свойства значение false. В db1 преобразуйте ваш первичный ключ в внешний ключ с некоторой новой таблицей tb1, содержащей это как первичный ключ. Итак, в конечном счете, при вашей репликации db db2 ограничение внешнего ключа не будет реплицировано и, таким образом, позволит вам делать то, что вы хотите.

Answer 3

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

Answer 4

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

Ваш вопрос здесь можно рассматривать как вопрос о том, можно ли использовать процесс репликации для разрыва этого базового принципа репликации.

Таким образом, ответ отрицательный, но меня все еще интересуют причины, позволяющие сформулировать этот вопрос. Должен ли я сказать, что этот вариант «двойного первичного ключа» рассматривался как способ решения другой проблемы? Я думаю, вы должны вернуться к этой первоначальной проблеме и попытаться найти другой способ ее решения.

Answer 5

Я сделал свое домашнее задание и пришел к выводу, что вы можете отказаться от ограничений на подписчике .

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

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