Синхронизация платформы с БД SQL: Начало работы

Мне кажется, что Microsoft Sync может быть для вас хорошим вариантом. Здесь есть обзор синхронизации баз данных, http://msdn.microsoft.com/en-us/sync/bb887608.aspx . Взгляните на него и посмотрите, соответствует ли он вашим потребностям. Звучит как идеальное решение вашей проблемы.

Это по сути называется распределенными вычислениями.

В любой подобной системе, над которой я работал, я обычно использовал N-уровневую архитектуру, чтобы позволить эпизодическое подключение клиентской программы к серверу базы данных на задней стороне для CRUD-операций. Любая работа, которую выполняет клиент, считается работой без подключения, поскольку он не взаимодействует с сервером до тех пор, пока не сохранит свои изменения.

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

Я бы сказал, что использование репликации Merge с локальными установками Sql Express - это, конечно, подход "кувалды". Не расстраивайтесь из-за этого, мы все делаем это время от времени :P.

EDIT

Я сам не использовал Sync Framework, но он кажется неплохим. Посмотрите Sync Framework Developer Center для получения дополнительной информации о нем.

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

Проекты, над которыми я работал (давным-давно), использовали compact framework и activesync с бэкэндом Access или SQL Server, потому что было слишком дорого постоянно подключать каждое устройство, как телефон. Они брали устройство в поле, получали доступ к данным из отключенной базы данных, делали свои изменения и синхронизировали их, когда возвращались в офис.

Если это то, что вы делаете, вы можете использовать их deviceID для определения того, какие случаи/строки нужны каждому устройству, но если вы думаете о разработке собственного решения для синхронизации, я думаю, что вы сражаетесь не в той битве. Это уже было сделано. Используйте проверенное решение синхронизации, ограничения и все такое, и сосредоточьтесь на критериях, которые можно использовать для ограничения синхронизируемых данных.

Похоже, вам нужно больше контролировать параметры слияния данных. С этим требованием я вижу 2 типа данных; Данные, принадлежащие участнику (обращение принадлежит участнику), и общие данные (справочные, основные данные).

В данном случае у меня было бы сочетание этих техник, чтобы сделать вещи наполовину быстрыми.

Например, основные и справочные данные меняются не так часто. Следовательно, нам не нужно синхронизировать очень часто, но нужно иметь контроль над изменениями и должны / должны выполняться централизованно. В этом случае я бы внес изменения в свою центральную базу данных и использовал подход кувалды.

Для транзакционных данных, предполагая однократную направленность, в этом случае член может изменять только кейсы / строки, которые принадлежат ему / ей, может быть реализовано многими способами.

Как упоминалось выше, вы можете использовать Sync Framework Developer Center или ActiveSync.

Поскольку пороговые значения не такие строгие, как в КПК или карманных компьютерах, мы можем попробовать и ручной подход, поскольку у нас есть ноутбуки. Реализация функциональной / технологической подпрограммы для подключения и передачи данных, которые создаются, обновляются и удаляются (в этом случае мы должны поддерживать флаг на уровне базы данных) с использованием BulkCopy Operations, наиболее распространенного подхода в этом сценарии (необходимо предоставить кнопку для участников, которые должны щелкнуть и вызвать, или службу для опроса и проверки подключения и автоматического запуска процедуры синхронизации).

/ КП

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

Для меня это звучит как проблема, которую можно разделить на 3 отдельных аспекта:

Процесс синхронизации

• Вы обязательно должны убедиться, что все строки имеют какой-то столбец last_update, чтобы ваш процесс синхронизации мог эффективно и надежно определить, какие данные уже обновлены - таким образом вы можете быть более агрессивными с количеством синхронизируемых записей.
• Я бы избегал сложных процессов синхронизации и просто использовал метод грубой силы везде, где это возможно. 14000 записей для меня не так много - с оптимизацией вы можете обнаружить, что можно синхронизировать все изменения, сделанные между подключениями, в разумные сроки. Если нет, то я, вероятно, был бы довольно либерален в отношении того, что вы синхронизируете, чтобы пользователи не работали с устаревшими данными, не осознавая этого.

Отправка изменений, внесенных в автономном режиме

Если это вообще возможно, я бы, вероятно, просто запретил изменения в автономном режиме - это невозможно, тогда вам следует рассмотреть возможность отправки изменений как отдельную (и, вероятно, довольно сложный) процесс сам по себе.

Не зная больше о приложении, трудно делать хорошие предложения, поскольку процесс синхронизации очень зависит от бизнеса, однако следует учитывать следующие моменты:

• Должны ли пользователи иметь возможность блокировать (или извлекать) элемент, чтобы предотвратить другие
• Следует ли отменять блокировку?
• Если блокировка отменяется, что должно произойти, когда кто-то пытается сохранить изменения (процесс слияния кажется разумным выбором)
• Должен ли кто-то иметь возможность редактировать элемент, который он еще не получил?

Если вы все же решите реализовать сложный процесс автономных изменений, то вы, возможно, захотите взглянуть на рабочий процесс, используемый в распространенной распределенной VCS, для вдохновения.

Изменение автономного хранилища данных

Вы можете найти использование SQL Compact или SQLite в качестве локального хранилища данных более элегантным решением (это, безусловно, упростит процесс установки) , если вы используете LINQ, я бы, вероятно, предпочел SQL Compact, поскольку он определенно поддерживает LINQ to SQL.

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

После многих дней борьбы с фреймворком синхронизации я подумываю отказаться от него и просто написать несколько простых сервисов и кода WCF. Мои требования довольно просты, односторонняя синхронизация с SQL2008 на SQL CE на мобильных устройствах. По моему опыту, его очень сложно настраивать (синхронизировать только некоторые поля и т. Д.), Он очень медленный и неэффективный. Я думаю, что Microsoft нужно еще немного поработать, чтобы упростить его использование.

Ура

Марк

http://code.msdn.microsoft.com/sync/Release/ProjectReleases.aspx?ReleaseId=3422 Это хорошее пошаговое руководство по использованию SQL Server CE, он должен отлично работать для того, что вы пытаетесь сделать, и занимает гораздо меньше места. Мне кажется, что функциональность, которую вы теряете, нисколько не мешает тому, что вы пытаетесь сделать.

Вы пытались фильтровать статьи репликации слиянием на уровне строк? Это уменьшит размер вашей строки 14 КБ до чего-то управляемого.

Мы использовали фреймворк Sync в нескольких наших проектах (один с сервером sql, другой с PGsql), поэтому я могу сказать, что он работает довольно хорошо.

Ознакомьтесь с этим пошаговым приложением, чтобы получить представление о том, что вы можете сделать.

http://code.msdn.microsoft.com/sync/Release/ProjectReleases.aspx?ReleaseId=4835

Это покажет вам, как синхронизировать данные между несколькими базами данных sql server. Вы также можете настроить хранимые процедуры «приращения», чтобы принимать настраиваемые параметры и фильтровать данные на основе этих параметров (например, людей, которых клиент-пользователь планирует посетить).

Я также предлагаю вам использовать рефлектор для декомпиляции кода фреймворка Sync в случае, если вы видите странные ошибки - иногда невозможно выяснить, где находится ошибка, пока вы не увидите, что исключение перехватывается в коде фреймворка. Redgate у меня отлично работает!

Дайте мне знать, если вам понадобится дополнительная помощь!