1. Контроль диапазонов ?
2. Оправданность idBranch в PK ?

GUID ?

Senya_L1. Например, использовать файл-ключ, в котором идентифицируется какому филиалу принадлежит БД (это уже есть) и задается начальное значение ID.
2. Вот и самому интересно :) Мне привычнее диапазоны.
3. GUIDы? Хмм... даже не знаю. Не нравятся мне гуиды. Хотя бы из того, что у меня MSSQL, а использование гуидов приводит к фрагментации индексов (в ветке MSSQL был небольшой холиварчик, если помните, про гуиды в PK).1. Техническая проблема подменяется организационной. Учитывая "законы" Мерфи, предпочитаю избегать влияние человеческого фактора.
2. В филиалах idBranch явно избыточен, если же его там исключить, то вместо одной схемы БД получим минимум две, с разными видами запросами и подходами к оптимизации. Да и в центре толку от idBranch немного, разве только все запросы будут строго пофилиальные, что маловероятно. Не для этого обычно собирают данные с филиалов. С другой стороны, начиная с 2008, если правильно помню, поле idBranch в филиалах можно будет сделать виртуальным, тогда единообразие сохраниться, но от усложнения запросов на слияние по ключу никуда не денемся. В общем, не то чтобы совсем безнадёжно, но на любителя, IMHO.
3. Против чувства не попрёшь, хотя аргумент слабоват.
Во-первых не просто индексов, а кластерных индексов. Но PK вовсе не обязательно должен быть кластерным, наверняка найдутся более удачные кандидаты с учётом типовых запросов.
Во-вторых:
1. фрагментации невозможно избежать в принципе, не в кластерном, так в остальных индексах
2. влияние этой фрагментации на общую производительность может быть практически незаметным
3. с 2005 и выше есть генерация последовательных GUID
В третьих, с учётом распределённой БД почти наверняка захотите воспользоватся штатными механизмами репликаций, а они построены на использовании GUID, который всё равно придётся добавлять в таком случае, так зачем от него сразу отказываться ?

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

Разумеется, если рассматривать исходную задачу ровно как описано в первом топике, копирование данных из одной таблицы филиала в одну центральную таблицу, то все эти заморочки ни к чему. И 1 и 2 способ вполне удовлетворительно решат исходную задачу. Но что-то мне подсказывает, что дело этим не ограничивается, а изобретается общий подход.

Senya_LChA1. Техническая проблема подменяется организационной.Задача идентификации экземпляра БД в любом случае возникнет. И в любом случаем некий сертификат должен использоваться для установки. Хотя бы потому, что предполагается использовать шифрование.Количество филиалов заранее неизвестно, соответственно, границы тоже. Делать диапазоны малыми на один филиал, может понадобиться несколько разных диапазонов на один филиал. При делении поровну имеем хлопоты с появлением новых филиалов. Какие-никакие, а всё-таки проблемы. Можно, конечно, выделять диапазоны гарантировано охватывающие количество возможных записей на филиал, но возможна неверная оценка. Кроме того, чисто теоретически филиалы могут не только появляться, но делиться, сливаться и исчезать. Но это только часть проблемы.
Главное, что "кто-то кое-где" должен следить за этими дипазонами. Кроме того, на местах никакие администраторы не должны проявлять самодеятельности и "следить", чтобы оставаться в рамках диапазона. В то же время, работа не должна остановиться, если дипазон внезапно закончится. В общем, надёжность такого решения лично мне кажется сомнительной. Слишком "силён" человеческий фактор.Senya_LЕдинственная разница между составным и несоставным PK мне видится в размере FK. Влияние на скорость это вряд ли окажет, так что непринципиально. Разве что случай слияния Ф-ов, тогда имхо использование диапазонов окажется более удобным и гибким подходом.В случае составного ключа производительность MS SQL принципиально не упадёт, но программистов запросто - запросы на слияние по идентификаторам усложнятся, надо будет всё время помнить о том, что слияние идёт по составному ключу. С точки зрения физической оптимизации, составной ключ, как и любой составной индекс, полезны, если в типовых запросах есть необходимость фильтрации(иногда группировки) по большинству этих полей, что обычно приводит к снижению IO. В противном случае, применение неоправдано и ведёт только к снижению его эффективности, увеличению индекса и усложнению запросов.

Сергей ВаскецовТогда уж можно просто сливать из Ф в Ц данные в разные БД, а на Ц-ом сервере просто иметь информацию, какой Ф какой БД соответствует. Безо всяких проблем с идентификаторами.С неменьшим успехом можно и в одну БД, но в разные таблицы, соответствующие филиалам. Но при любом из этих подходов будет несколько сложнее писать агрегирующие запросы, будут сплошные UNION. Да и оптимизатору будет явно сложнее найти эффективный планы выполнения подобных запросов. Не говоря уж о том, что придется хранить, верифицировать и активно использовать некую метаинформации о том, какие БД(таблицы) должны включаться в запрос, а какие нет. Иначе, можем запросто получить ошибку при выполнения запроса, так как БД(таблицу) удалили за ненадобностью(удалением филиала). Т.е., "нос вытащил - хвост увяз".