Обмен данными между удаленными местами

Question

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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