2013-04-23 2 views
1

Я разрабатываю клиентское приложение .net, которое использует Entity Framework для доступа к базе данных. Это многопользовательское приложение, где (иногда) нет изменений в течение нескольких дней, а иногда и сотни изменений.Перезагрузка кэша при изменении базы данных

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

Я попытался использовать SqlDependency, чтобы аннулировать мои кэши, но это может заставить меня перезагрузить очень много данных, когда только один бит изменился. Не очень хорошо для производительности. Также он срабатывает, когда приложение, которое использует SqlDependecy, что-то изменяет в данных, поэтому одно изменение получает кэш обновляется дважды.

Поскольку я никогда не разрабатывал что-то с таким количеством кеширования, я не согласен с тем, как мне лучше идти дальше. Каков наилучший способ сделать это?

+0

Почему одноразрядное изменение заставляет вас перезагружать очень много данных? – Paparazzi

+0

Ну, может быть, я что-то не так, но когда я получаю уведомление, я не знаю, что именно было изменено, поэтому я не могу просто перезагрузить измененные данные. Мне нужно переустановить все, что могло быть изменено под SqlCommand. Например, все элементы в таблице «A», где fk ... = x. Могут быть довольно некоторые данные. – Patrick

+0

Поймите, но один бит по-прежнему не заставляет вас перезагружать все данные. Вы можете прочитать прочитанные данные и только обновить данные, которые были изменены. Или вы можете реализовать триггер SQL, который записывает изменения, поэтому вам нужно только проверить эту таблицу. – Paparazzi

ответ

1

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

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

+0

Ваш ответ определенно заставил меня идти. Я просто не уверен, следует ли использовать триггеры или «отслеживание изменений», предоставляемые «SQL Server» (2008 R2 и новее). С решением, использующим триггеры, я получил больше контроля, но должен делать это для каждой таблицы. Или есть возможность сделать это для всех таблиц за один триггер? (Я никогда не использовал триггеры раньше) – Patrick

+1

Я предлагаю оба. Изменить отслеживание для уведомления. Затем нажмите, чтобы определить, какие данные изменились. Я не думаю, что у вас может быть один спусковой крючок для всей таблицы и сомнение в том, что это наилучшее решение. Конечно, у вас есть несколько таблиц, которые не обновляются пользователями. И вы не хотите запускать триггерные таблицы. Вы могли бы написать несколько триггеров в одну и ту же таблицу. – Paparazzi

Смежные вопросы