Один способ - с таблицами очередей.Поместите триггер вставки / обновления в таблицы, чтобы перенести любые изменения в очередь.Если строка таблицы была вставлена, затем обновлена дважды, то в очереди будет информация о вставке, обновлении, обновлении.Затем клиенты запрашивают изменения из очереди на основе последнего времени извлечения из очереди.Преимущество очередей в том, что нагрузка остается небольшой.У вас может быть таблица с 100 000 строк, но вы загружаете только 3 или 4 необходимых вам редактирования.
Другой способ - захватить всю таблицу.Сделайте массовую вставку к промежуточному столу.Затем выполните обновление / вставку на основе набора для обновления существующих строк, вставки новых строк.
Любое решение, которое вы придумаете, будет иметь 800-фунтовую гориллу в комнате.Это слияние.Если 2 пользователя отправляют конфликтующие данные в одну и ту же строку, возникает проблема.Вы можете уменьшить шанс, синхронизируя чаще.Таблица очередей лучше подходит для частой синхронизации, поскольку вы только синхронизируете новые правки с прошлого раза.Если вам очень повезло, природа вашего приложения заставит каждого клиента касаться только своих «собственных» данных, поэтому объединение не будет проблемой.
Вы находитесь в среде локальной сети.Просто есть 1 база данных, к которой имеют доступ все клиенты.Это традиционная модель для приложений реляционных баз данных, которая работает очень хорошо.