Контроль изменений в сетевых БД

При создании приложений работающих с отсоединенными БД довольно часто возникает вопрос, как уведомить всех клиентов (программы-клиенты) о том, что в БД произошли изменения. Модель отсоединенных БД не подразумевает наличия такого рода уведомлений от сервера, т.е. клиент должент сам беспокоиться о проверке наличия изменений.
Все способы контроля изменений, основаны на периодическом опросе БД. Периодичность запросов зависит от требуемой актуальности данных, поэтому таймер может иметь настройку от нескольких секунд до часов. Сразу следует отметить, что данным параметром злоупотреблять не следует, т.е. не стоит нагружать сервер запросами через 1 секунду, если в этом нет острой необходимости. Из своего опыта могу отметить, что вполне достаточно периода 30-60 сек. (для редко обновляемых 5-10 минут), для особо нетерпеливых пользователей желательно также оставить кнопку обновления.

Ниже приводятся (встречаемые мной) способы контроля изменений при использовании СУБД SQLServer:

1) Периодическое обновление требуемых данных. Т.е. обычный повтор выборки.
Достоинства:
- не требует организации дополнительных способов обработки данных
- Недостатки: нагрузка на сервер и клиента даже при отсутствии изменений (особенно актуально, когда повторно выбираются таблицы в десятки/сотни тысяч строк и/или представления сложной структуры)

2) Проверка контрольной суммы объекта, если сумма изменилась, делается повторная выборка данных на клиента. Для этого способа я использую следующий запрос Запрос возвращает контрольное число для объекта. Клиент запоминает это число и впоследствии сверяет с ним последующие значения.
Достоинства:
- минимальная нагрузка на клиента при отсутствии изменений.
- возможность применения к любому объекту (запросу), т.е. в качестве объекта может выступать любая сущность БД, представляющая требуемую выборку (таблица, представление, ХП)
- возможность настройки контроля требуемых столбцов, т.е вместо * в запросе можно указать перечисление столбцов. Пример: Это позволяет уменьшить время вычисления контрольной суммы, особенно актуально при использовании по отношению к представлениям.
Недостатки:
- запрос показывает были изменения или нет, при обнаружении изменений, повторная выборка должна производится на весь объем данных.
- контрольная сумма не является 100% гарантом наличия изменений, т.е. существует вероятность (хоть и черезвычайно малая), что два некоторых различных набора данных в результате дадут одинаковое контрольное число

3) Фиксация изменений. В данном случае в талицах БД добавляется столбец "время изменения". Запросы клиента проверяют наличие данных в таблицах с временем больше времени предыдущего запроса.
Достоинства:
- клиент получает только строки с изменёнными данными и присоединяет их к "своему набору", что положительно сказывается на быстродействии системы
Недостатки:
- необходимость изменения структуры таблиц
- при использовании запросов обращающихся к нескольким таблицам необходимо проверять каждую таблицу на наличие изменений. Особенно это критично, когда используются многоуровневые представления или ХП, и отследить исходные таблицы довольно проблематично
- усложнение запросов обработки данных

4) Этот способ является более сложным и также требует дополнительных измений стуктуры БД. Для реализации в БД следует создать таблицу, которая будет хранить записи об изменениях, с указанием в какой таблице и для какого ID произошли изменения, а также создание триггеров для "подконтрольных" таблиц, которые будут регистрировать эти изменения в указанной таблице. Встречаются варианты, когда для каждой таблицы создается "контрольная" таблица. Как правило оба варианта данного способа используется в составе систем логирования изменений.
Достоинства:
- как и у предыдущего способа
Недостатки:
- как и предыдущего способа
- увеличение количества таблиц в БД
- рост размера БД за счет служебной информации
- использование триггеров


Что можно сказать о целесообразности применения того или иного способа? Все они имееют право на существование, и выбор зависит от того результата, который требуется разработчику.
Также следует отметить, что все операции по контролю за обновлением желательно проводить в фоновом потоке, дабы не напрягать пользователя ненужными "зависаниями"
Если во время обновления пользователь меняет какие-либо данные, необходимо предусмотреть выдачу предупреждения о том, что редактируемые им данные были изменены кем-то еще, и предложить вариант действий (получить актуальные данные/оставить текущие) . Эту возможность проще реализовать с 3 и 4 способом.

31