Рекомендуемая основа для агрегирования данных

Question

У нас есть приложение, которое будет собирать и хранить данные на локальных компьютерах WinXP с помощью Microsoft SQL Server Compact. Мы хотим объединить эти данные в единый полноценный SQL Server для отчетов и архивирования. Передача данных должна быть достаточно непрерывной (т.е. не пакетной), хотя допустима некоторая задержка (максимум минута или две).

Данные - это односторонняя передача от сборщиков к серверу. Сборщикам никогда не нужно знать, что делают другие сборщики, и основной сервер никогда не будет обновлять данные обратно на сборщике. Текущие планы рассчитаны на 5 сборщиков, но они практически не ограничены для масштабируемости.

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

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

Прямо сейчас у нас есть два кандидата на технологию:

1. Репликация SQL
2. Службы Microsoft Sync

У нас мало опыта с первым, но мы знаем, что настройка подписок и т. Д. В SQL Server является болезненной, а отладка их не увлекательна, поэтому мы пытаемся найти альтернативу.

Мы почти ничего не знаем о # 2, только то, что он был предложен в качестве альтернативы для передачи данных устройства на сервер.

Есть ли у кого-нибудь опыт в сценарии такого типа или с одной / обеими этими технологиями или с чем-то, о чем мы не думаем, что они могут поделиться? SQL Compact на коллекторах является фиксированным требованием. SQL Server на сервере не требуется, но желателен, так как у клиента уже есть.

Answer 1

Я использовал Microsoft Sync Services до того, как он был полностью выпущен. Мне понравилось, и, кажется, идеально подходит для вашего приложения.

Я рекомендую, если вы хотите упростить себе жизнь, - это использовать GUID (уникальный идентификатор SQL Server) в качестве первичных ключей во всех таблицах, которые вы хотите синхронизировать с главным сервером. Это предотвратит коллизии и много лишнего кодирования.

Одно предупреждение: я слышал, что службы Sync Services значительно изменились после выпуска первой версии, поэтому моя информация, вероятно, устарела.

Answer 2

В итоге я выбрал вариант 3: ни то, ни другое. Вместо этого мы просто периодически (настраиваемые пользователем, но по умолчанию 5 секунд) используем класс SqlBulkCopy для копирования записей. Это работает хорошо, потому что позволяет нам передавать IDataReader, поэтому мы локально открываем таблицу с помощью TableDirect, ищем самый высокий RowID из удаленной таблицы, а затем передаем читатель в класс WriteToServer.

Answer 3

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

Answer 4

Попробуйте синхронизировать и расскажите нам, как это происходит :) Я видел событие MSFT, и эти парни говорят: «Я добавил эти 3 строки кода, и все просто синхронизируется ... wooohhooo».

Звучит как путь ко мне.