Кэширование данных в базе данных SQL CE

Question

Фон

У меня есть база данных SQL CE, которая постоянно обновляется (каждую секунду).
У меня есть (веб) приложение, которое позволяет пользователю просматривать данные в режиме реального времени. В какой-то момент пользователь может нажать кнопку «сделать снимок», и он откроет снимок в другом окне.
И затем в этой форме есть кнопки «печать» и «загрузка», которые либо сгенерируют страницу для печати, либо будут передавать данные в виде файла CSV - но должен использоваться тот же моментальный снимок данных , т.е. Я не могу пойти в БД, чтобы получить последние данные для этого.

Подробности

• База данных SQL CE предоставляется через веб-службу WCF.
• Снимок состоит из 500 записей по 10 столбцов в каждой. Время истечения на снимке 2 часа достаточно.
• Это приложение с низким трафиком, поэтому я не ожидаю более нескольких (5) подключений одновременно.
• Потеря снимка не имеет большого значения, пользователь может просто создать новый.
• осуществляется через самодостаточный веб-сервис WCF с использованием Linq-to-SQL.
• Веб-сайт ASP.NET MVC, размещенный на UltiDev Cassini.
• база данных и веб-сайт, скорее всего, будут находиться в одном окне при развертывании. Все приложение связано с интранетом.

Задача Мне нужно кэшировать моментальный снимок данных в тот момент, когда пользователь нажал кнопку «сделать снимок», чтобы я мог использовать те же данные для создания страницы печати или создания файла для загрузки.

Решение 1: Каждый раз, когда необходимо создать снимок, я буду создавать таблицу в базе данных. Поскольку в SQL CE нет временных таблиц, мне нужно будет их самостоятельно почистить.

Решение 2: Кэшируйте снимок в памяти на сервере БД или веб-сервере.

Вопрос: Что-то не так с предлагаемыми решениями? Любые другие решения?

Answer 1

Рассматривается типичная модель использования . Приводит ли большинство снимков к печати или экспорту или к тому и другому одновременно?
Если это так, мы могли бы также «получить его в памяти» (временно) в форме неблокирующего (асинхронного) оператора выбора с устройства на сервер. Таким образом, данные «будут там» или находятся на подходе, когда пользователь решит их использовать.

Если, с другой стороны, многие моментальные снимки в конечном итоге не используются эффективно, решение № 1 кажется вполне приемлемым (возможно, таблицу можно назвать по имени учетной записи / пользователя, следовательно, гарантируется «самоочищение» в зависимости от количества снимков a пользователь может поддерживать в определенный момент времени (хотя он, кажется, всего один, даже с допуском его потери).

Answer 2

500 строк на 10 столбцов на самом деле не очень большие. Для простоты в этом случае я мог бы просто генерировать данные CSV в то же время, когда я генерирую исходную страницу снимка, а затем помещать данные CSV в скрытое поле на странице снимка. Кнопки «Печать» и «Загрузить CSV» затем отправляют форму, содержащую данные CSV, на страницу «Печать», которая генерирует версию для печати из опубликованных данных CSV, или страницу, которая передает поток CSV непосредственно обратно в браузер клиента, соответственно. , Таким образом, по крайней мере, у вас не будет проблем с очисткой, и вы избежите необходимости кэшировать на сервере что-либо (либо в самом кэше, либо в базе данных), которое может в конечном итоге никогда не использоваться в все.

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