Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Кэширование данных и репликация (Occasionally Connected Application)  [new]
Андрей Прохоров 79
Member

Откуда:
Сообщений: 8
Доброго времени суток!

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

В магазинах работает WinForms приложение с базой SQL Server Compact 4.0, которая используется для кэширования данных. При первом подключении, программа загружает данные магазина в кэш и далее работает с ним. Все изменения выгружаются на сервер с периодичностью в 10 минут. Данные магазина включают в себя информацию о магазине, сотрудниках, товарах. Дополнительно к этим данным в кэш загружаются товары других магазинов в регионе, но только если магазин-владелец разрешил публикацию этих товаров.

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

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

Заранее спасибо!
7 авг 12, 03:53    [12972363]     Ответить | Цитировать Сообщить модератору
 Re: Кэширование данных и репликация (Occasionally Connected Application)  [new]
Андрей Прохоров 79
Member

Откуда:
Сообщений: 8
up
7 авг 12, 20:05    [12977556]     Ответить | Цитировать Сообщить модератору
 Re: Кэширование данных и репликация (Occasionally Connected Application)  [new]
Андрей Прохоров 79
Member

Откуда:
Сообщений: 8
up
7 авг 12, 22:46    [12978187]     Ответить | Цитировать Сообщить модератору
 Re: Кэширование данных и репликация (Occasionally Connected Application)  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
Андрей Прохоров 79
Есть ли какие-нибудь способы отслеживать не только изменения записей, но и видимость записей, зависящих от измененной.
Есть. А проблема то в чем?
7 авг 12, 23:56    [12978339]     Ответить | Цитировать Сообщить модератору
 Re: Кэширование данных и репликация (Occasionally Connected Application)  [new]
Андрей Прохоров 79
Member

Откуда:
Сообщений: 8
Mind
Андрей Прохоров 79
Есть ли какие-нибудь способы отслеживать не только изменения записей, но и видимость записей, зависящих от измененной.
Есть. А проблема то в чем?

Проблема в том, что я не нашел таких средств. Буду рад, если подкинешь мануал.
8 авг 12, 00:01    [12978346]     Ответить | Цитировать Сообщить модератору
 Re: Кэширование данных и репликация (Occasionally Connected Application)  [new]
Андрей Прохоров 79
Member

Откуда:
Сообщений: 8
Задача примерно следующая: клиент обращается к серверу с запросом GetChanges(lastSyncId id). Сервер возращает ему все фактические изменения (insert, update, delete) записей, к которым у пользователя есть или был доступ. А также, если пользователь был назначен руководителем, то он получает все данные подчиненного, если один из магазинов открыл филиал в его регионе, то получает данные этого магазина и таких ньансов много.
Можно, конечно, хранить полную историю изменений и потом анализировать ее, но это очень долго и требует множество коротких запросов к БД.
8 авг 12, 00:06    [12978359]     Ответить | Цитировать Сообщить модератору
 Re: Кэширование данных и репликация (Occasionally Connected Application)  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
Андрей Прохоров 79
Задача примерно следующая: клиент обращается к серверу с запросом GetChanges(lastSyncId id). Сервер возращает ему все фактические изменения (insert, update, delete) записей, к которым у пользователя есть или был доступ. А также, если пользователь был назначен руководителем, то он получает все данные подчиненного, если один из магазинов открыл филиал в его регионе, то получает данные этого магазина и таких ньансов много.

Готовых решений, которые будут учитывать все ваши ньюансы конечно же нет, так что мануалом тут не отделаешься, нужно писать свой механизм. Вариантов много:
1. Отслеживать ключевые изменения триггерами и обновлять "вхолостую" таблицы видимость которых зависит от этих изменений. Тогда при следующей выгрузке все нужные таблицы перезальются на подписчиков.
2. Можно, на тех же триггерах, инициировать частичный/полный сброс кэша только на определенных подписчиках в зависимости от логики.
3. А еще можно на издателе хранить ID-шники всех отреплицированных таблиц в разрезе подписчиков. А при вызове GetChanges формировать таблицы для репликации, с учетом видимости данных для текущего юзера, потом мержить их с ID-таблицами и таким образом получать дельту. И уже только эти изменения копировать на подписчики.

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

Андрей Прохоров 79
Можно, конечно, хранить полную историю изменений и потом анализировать ее, но это очень долго и требует множество коротких запросов к БД.
Напишите один длинный запрос.
8 авг 12, 01:15    [12978497]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить