В свое время я тоже мудрил над этой проблемой. Сиды и последовательная нумерация записей - это не есть хорошо. Действительно, наиболее хорошим решением является именно GUID (uniqueidentifier). А почему все остальное не есть хорошо, я объясню. Если хотя бы один раз в жизни возникнет такая ситуация, что информация вносится в офисе M, а модифицируется в офисе N, вся твоя схема с обменом данными между офисами летит к чертовой матери (пардон за фольклорные руссонизмы). Ибо для синхронизации данных не достаточно информации о том, в каком офисе она вводилась. Еще нужна информация о том, где она в последний раз изменялась (а самый крантовый вариант - когда она изменяется одновременно и везде).
И это даже не есть самое поганое. Допустим, что в офисе N ничего никогда не модифицируется, просто скачивается информация офиса M. Теперь представь, что в самам офисе M кто-нибудю взял и просто удалил, либо изменил одну запись (которая ранее уже была передана в офис M). Каким образом сервер должен догадаться, что именно эту запись ему нужно удалить и перекачать повторно, а все остальные не трогать?
Теперь о том, почему Uniqueidentifier - это хорошо.
1. На этот тип завязаны стандартные механизмы репликации.
2. GUID генерится гарантировано уникальным, что при любых раскладах исключает конфликты формирования идентификаторов.
3. 16-байтовость GUIDов делает их поистине неисчерпаемыми по сравнению с идентификаторами малого размера с последовательной нумерацией, использование которых потенциально опасно переполнением разрядной сетки (особливо в совокупности с разбиентием интервалов с помощью SID).
Остается вопрос - как же отличить те записи, которые должны передаваться после модификации/удаления/добавления из одного офиса в другой? Во-первых, рпешение этих вопросов можно поручить стандартным механизмам репликации. Во-вторых, можно завести дополнительные поля. Если тебе позарез нужно знать "место рождения" записи (именно рождения, а не модификации!), то заведи такое поле. Если тебе нужно знать именно место модификации, то заведи соответствующее поле. Если тебе еще нужно знать дату/время последней модификации, заведи еще и такое поле. Вот только с удалением может возникнуть проблема. Дело в том, что все вспомогательные поля несут какую-то информацию только по тем записям, которые реально существуют в природе. А вот если запись удалили, то она больше не существует. И информацию о том, почему данная запись перестала существовать, кто или что стало причиной ее удаления - в простой структуре уже не разложишь. Нужно вести журнализацию операций. А там возникает вопрос, до какого века какой эры эта журнализация должна жить и что в ней существенно, а что нет (может оказаться, что существенно всё, но очень редко, а записи создаются и удалаяются сотнями каждую минуту).

Если сравнивать использование в качестве PK совокупности Int_RecID + TinyInt_OfficeID с PK на одном GUID_ID, то, конечно же, размер PK будет меньше, и, следовательно, быстродействие выше. Но выиграв в быстродействии в 2 раза и проиграв в функциональности в те же два раза, вы проиграете в 2000 раз, потому что приложение окажется никому не нужным, если оно не сможет справиться хотя бы с 1% всех жизненных ситуаций. При этом к нему резко упадет доверие пользователей, некоторые из которые могут просто устроить саботаж даже в тех ситуациях, с которыми программа вполне может справиться. Это просто из жизненного опыта.
Теперь по делу. Быстродействие по некоторым запросам, в которых несколько таблиц объединяются по JOIN, для первого и второго варианта PK врядли будет отличаться более чем в два раза. А общее быстродействие, субъективно воспринимаемое пользователем приложения, процентов на 20, не более. Но что вы будете делать, когда выяснится, что обмен информацией (хотя бы некоторой ее части) между офисами должен производиться в обе стороны при условии возможности ее модификации (а также удаления, обновления) одновременно во всех офисах? При выборе первого варианта вам останется либо застрелиться, либо уволиться. При выборе второго варианта просто порадуетесь, что для этого у вас все готово.

GUID-PK лучше делать кластерным, проверено на практике. Не смотря на самые умные мысли, высказанные в литературе и на данном форуме. Если строго следовать теории, то получается, что GUID-поле, которое по своей сути не может интерпретироваться как поле, содержащее последовательно увеличивающиеся значения не очень подходит для кластерного индекса (а именно для полей с последовательно увеличивающимися значениями наиболее эффективно применять кластерный индекс). Использование некластерных индексов для такого поля должно быть более эффективным. Поддавшись теоретическим изыскам, я в своем проекте (в котором почти все таблицы имеют GUID PK) сделал PK всех таблиц некластерными (плюс, естественно, обновил статистики и полностью перекомпилировал скрипты). После чего получил жуткие тормоза (быстродействие упало раза в три. Вернул кластерные индексы обратно - все встало на свои места. Так что практика не всегда подтверждает теорию (либо практики не всегда правильно интерпретируют теорию, а теоретики - практику).
Удачи.

2 ВладимирМ. Извините, в последнее время на работе поджимает, поэтому на форуме редко появляюсь... А по сути вопроса примерно так. Если модификация записей возможна в нескольких офисах, то требуется двусторонняя репликация. Репликация транзакиций не рассматривается, поскольку для удаленных офисов и медленных каналов она не годится. Snapshot-репликация может производиться только очень редко, если объемы данных велики, и она также не годится для двунаправленного обмена при модификациях записей на обеих сторонах. Остается Merge-репликация, для организации которой вам в любом случае потребуется ROWGUID-поле типа Uniqueidentifier. Если вы его изначально не заведете в таблице, оно появится само. Я ответил? Или еще требуется перебор вариантов обмена через DTS? Главное понимать, что любой вид репликации использует какую-то дополнительную информацию. При репликации транзакций, в частности (которая для нашего случая не подходит), используется поле TimeStamp, которое также возникнет в таблице помимо вашего желания... От подобной информационной избыточности вы никуда не денетесь. Важно эту информационную избыточность совместить со стандартными механизмами, использующимися для классических решений подобных задач (IMHO), а не изобретать велосипед. Потому что изобретенный велосипед скорее всего окажется хуже проверенного жизнью и специалистами MS.

Согласен. Только на создание собственных механизмов репликации можно и жизнь потратить... А потом, уже на пенсии, оглянешься и задумаешься: "И на фига же я столько сил на изобретение колеса потратил?"....