( Отказ от ответственности : я предполагаю, что вы уже рассмотрели вопрос об использовании .NET DataSets и обесценили их, учитывая, что они предназначены для решения только проблемной области, в которой вы находитесь описывающее.)
Раньше я работал в компании, которая разработала систему торговых точек для своей национальной сети магазинов. Основная база данных хранилась в головном офисе, в то время как у каждого магазина была своя сокращенная версия этой базы данных, хранящаяся локально на этом сайте. По сути, каждый магазин находился в автономном режиме все время, поэтому описываемую вами ситуацию не совсем, однако нам пришлось столкнуться с некоторыми проблемами синхронизации / репликации, которые, как я полагаю, вам придется решать.
Наш обмен данными происходил каждую ночь: магазины подключались к головному офису в заранее установленное время, загружали пакет изменений данных и загружали аналогичный пакет изменений данных, которые должны были применяться к локальной базе данных этого магазина. Затем у нас были так называемые «механизмы синхронизации данных» на обоих сайтах (головной офис и магазины), которые обрабатывали эти пакеты данных, складывая изменения (вставки / обновления / удаления) обратно в соответствующую базу данных.
Когда вы выполняете базовую репликацию данных, как это, есть ряд потенциальных ловушек, как упомянул Серхио. Одним из них является идентичность, а именно то, как вы получаете первичный ключ, который однозначно идентифицирует строку таблицы. Другой - управление версиями, и как вы обрабатываете конфликты между различными версиями одной и той же строки.
В нашем случае мы упростили себе задачу (-ier!), Используя GUID в качестве первичных ключей вместо использования автоинкрементных столбцов. Использование GUID не без проблем, но в нашем случае это означало, что мы могли бы назначить первичный ключ для новой строки данных и не беспокоиться о том, чтобы кто-то другой использовал его.
Я немного запутался в том, как мы справились с проблемой управления версиями (это было несколько лет!), Но по памяти я думаю, что у нас было две метки времени в каждой строке таблицы: одна из них записывала дату / время, когда строка был обновлен в головном офисе; другой, когда это было обновлено в магазине. В каждом ряду также было два «номера версий», которые указывали версию ряда в головном офисе и в магазине. Сверка данных включала сравнение этих временных меток и номеров версий друг с другом, с последним изменением, «выигравшим» (при условии, что другая сторона, конечно, не изменила строку).
Как отмечает Серхио, вашей самой большой проблемой будет обработка конфликтов согласования данных. В нашем случае это произошло, когда магазин и головной офис изменили один и тот же элемент данных в один и тот же день. Мы работали над этим, всегда терпя неудачу с изменениями в цехе, и создавая специальное приложение для сверки данных в головном офисе, которое вовлекало пользователя, визуально сравнивающего и объединяющего две конфликтующие версии элемента данных. Теоретически, я полагаю, вы могли бы автоматизировать объединение различных версий, используя некоторые пользовательские правила обработки, но вам нужно было бы взвесить стоимость разработки чего-то подобного в сравнении с вероятностью возникновения конфликтов. По памяти это никогда не было такой большой проблемой для нашей системы, несмотря на большое количество магазинов (несколько сотен), вносящих изменения в один и тот же набор данных. YMMV конечно.