Paul SacksЯ так думаю, что здесь репликаци не пригодится. Практически простейший вид слияния информаци. Я , правда, не смого прочитать , что написали коллеги, но с триггерами придется поработать. Похожая идея работает и у меня, только все это на примере складов. Для своей реализации я использую глобальные коды, которые и сам раздаю. В противном случае Вы не сможете идентифицировать информацию.
Это смотря, какая РСУБД. Например, для ASA описанная проблема вообще яйца выведенного не стоит, там все это штатными средствами решается - фактически будет одна консолидированная БД и удаленные БД, информация которых является зеркальной частью консолидированной БД, где можно определить, какие узлы какую информацию должны видеть (например только свою по узлу или же общую между узлами), спокойно менять область видимости информации между узлами (т.е. меняем код узла у записи и она автоматом удаляется с узла где была и добавляется в новый указанный узел) и решать конфликты обновления версий информации с помощью написания триггеров разрешения конфликтов, когда например 2 узла владеют общей информацией, одновременно поменяли ее, во время репликации в консолидированную БД это обнаруживается и срабатывает триггер, где мы спокойно можем определить, чья информация будет принята и сделать любые другие действия (например для узла, кому отказано, записать в табличку причину отказа проведения их изменения, которая опять же по репликации автоматом попадет к ним вместе с правильной версии записи). Если же РСУБД не поддерживает штатно таких наворотов, то конечно придется помучаться, чтобы сделать хотя бы часть такого функционала. Однако в любом случае денормализацию таблиц допускать нельзя.

guest-iiiiА не много ли геморрою?...
Может проще в таком случае вести центральную базу клиентов, из которой таблицу клиентов реплицировать по "филиалам"?

И что - новому клиенту сидеть ждать, пока они позвонят в центр, введут информацию в централизованный справочник и она спуститься вниз ?

guest-iiiiИ не случится ли так, что собрать по одному клиенту не получится? типа он заведен дважды в разных филиалах, но id у него разный?
А вот здесь в силу вступает грамотное проектирование и тема Исскуственные ключи vs Натуральные ключи.

guest-iiiiА не скажет ли автор топика в чем смысл объединять филиалы ломбарда вместе? зачем? Выявлять "постоянных" клиентов? или просто - формировать баланс/прибыль/убытки?
Наверное ему хочется иметь консолидированную БД по всем филиалам, я думаю его проект не будет ограничиваться только списком клиентом, иначе вообще не понятно, зачем что то делать.

Если у него есть стабильные выделенные каналы связи, то и разговору нет вообще БД на филиалах держать. Если же у клиентов модем (а то и просто дискеты и проводники в поезде деревня Гадюкино-Москва), будет забавно посмотреть, как он будет через веб-интерфейс с центральной БД работать или же "запускать" удаленно ХП :) А даже если и есть каналы связи, то события 25 мая показали, что оффлайн репликации очень даже выгодная штука - у кого они есть продолжали себе в местную БД данные вбивать и не обращать внимания, есть там свет в Москве, работает ли Рунет, в отличие от остальных, которые просто сидели и куковали :)