Обмен данными между удаленными точками

Question

В настоящее время я оцениваю, как наилучшим образом обмениваться данными между офисами в разных географических точках.
Мое предпочтение отдается SQL Server Merge Replication и имеет основную базу данных и несколько подписчиков.

Система также должна будет отключить несколько рабочих мест (нет или мало возможностей подключения на строительных площадках).

Объем данных не будет большим, мы говорим об обмене данными из пользовательской системы ERP между заводом-изготовителем, несколькими региональными офисами и рабочими местами.

Sync Framework также выглядит хорошо и, кажется, имеет хорошую поддержку в SQL Server 2008.

1. Какую еще проверенную систему следует исследовать, чтобы ответить на эти потребности?
2. Для тех, у кого есть опыт обмена данными в подобной среде, есть ли у вас какие-либо рекомендации и советы?
3. Насколько сложно вам справляться с конфликтами данных?

Answer 1

Определенно придерживайтесь репликации SQL Server, затем решите перейти по пути создания собственной структуры репликации. Я видел, как некоторые приложения становятся ужасными.

У меня были среды, которые настроены для репликации моментальных снимков в отключенной модели, но удаленные сайты были доступны только для чтения. Они работали достаточно хорошо с минимальными проблемами.

Мне также будет интересно услышать опыт людей в рамках синхронизации.

Возможно, вам захочется взглянуть на то, что называет microsoft smart clients, о котором сообщается в microsoft, о приложениях, которые могут иметь временную сетевую связь.

Answer 2

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

1. Нашего выбора для «не связанных» ВСЕГДА сайтов для реализации веб-репликации слияния. Обмен данными происходит еще быстрее, чем через VPN (так как у нас также есть комбинация реплик слияния ЛВС). Я легко получаю скорость от 30 до 40 строк в секунду через сеть (512 Down/128 Up, shared), в то время как я получаю 5 строк в секунду через LAN (за границей, 256 Up/Down, выделенный). Не спрашивайте меня, почему ...
2. Советы многочисленны: подписка должна быть типа клиента (данные распространяются в основном от подписчика до издателя до распространения). Первичные ключи всегда должны быть GUID по многим причинам exposed here, но также и для проблем репликации: мы уверены, что любой вновь созданный отчет сможет найти путь к издателю, поскольку его ПК будет уникальным. Более того, у меня недавно возникла проблема с несовместимостью с одной из моих репликаций (плохой опыт, выставленный here), где я был очень рад не использовать естественные ключи, поскольку проблема возникла в потенциальном столбце «естественный ключ».
3. Контакты данных должны быть в основном ограничены проблемами организации работы, где (по общему мнению по плохим причинам) одни и те же данные изменяются разными пользователями в разных местах одновременно.Поскольку наше «ПК - это правило GUID», у нас нет конфликтов из этих конкретных ситуаций.
4. У каждого должна всегда быть возможность изменять структуру базы данных, даже если выполняются репликации. При выполнении процессов репликации слияния можно продолжать добавлять поля, индексы, ограничения. Я также нашел обходное решение для добавления таблиц без повторной инициализации процесса репликации (выставлено here, все еще не понимало, почему я был отклонен на этот ответ!)