Какой подход выбрать для кэширования уникальных списков автоматических предложений для пользователей?

Я делаю приложение (asp.net/c#), которое будет автоматически предлагать пару полей, которые вводят пользователи. В конечном итоге каждый пользователь создаст свой собственный список автоматических предложений. Каждый раз, когда они добавляют элемент, если это новое слово, оно будет добавлено в их список автоподсказок, как и в gmail.

Мне было интересно, как большинство людей поступает по этому поводу? Звонок на сервер для каждого нажатия клавиши кажется не очень эффективным? Должен ли я сделать огромный файл xml с одной записью для каждого пользователя? XML-файл для каждого пользователя? как мне кэшировать это, чтобы сделать его эффективным?

Всевозможные вопросы, но в основном я ищу лучшие практики. Спасибо.


person naspinski    schedule 04.02.2009    source источник


Ответы (3)


Я бы сохранил значения в базе данных (где вы, возможно, храните их профили пользователей) и вытащил значения в сеанс ASP.NET, когда пользователь входит в систему. Затем просто используйте значения из сеанса для значений автозаполнения. Таким образом, вам нужно будет только один раз попасть в базу данных при входе в систему.

person mkchandler    schedule 04.02.2009

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

Запрос на стороне клиента
Вы можете запросить базу данных со стороны клиента (через AJAX), когда пользователь начинает вводить текст в текстовое поле. В этом случае рекомендуется подождать, пока в поле не будет не менее 3 символов, прежде чем запрашивать предложения у сервера. Это немного уменьшает количество запросов и трафик между клиентом и сервером.

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

Кэширование
Если вы используете этот метод, вы можете оптимизировать процесс, кэшируя ответ в определенных ситуациях.

Предполагая, что запрос запускается только после того, как 3 символа находятся в текстовом поле, вы можете кэшировать весь результат. Любые дополнительные символы, добавленные в текстовое поле, не увеличат количество возвращаемых результатов. Таким образом, вы можете просто продолжать фильтровать кешированные результаты. Однако, если пользователь удаляет символ, вы можете обновить кеш, чтобы убедиться, что у вас есть наиболее подходящие совпадения с автоматическим предложением.

Предварительная загрузка на стороне сервера
Соберите все эти данные на стороне сервера и отправьте их вместе с запросом страницы. (Вы можете отправить его как массив javascript где-нибудь, на который можно сослаться в событии onchange текстового поля. Таким образом, вам не нужно делать какие-либо вызовы AJAX.

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

person EndangeredMassa    schedule 05.02.2009

Чак Норрис рекомендует, в зависимости от вашей среды JavaScript, чтобы вы могли создавать проверки на стороне клиента перед вызовом сервера, чтобы увидеть, есть ли заданное количество символов или слов, написанных в поле. Файл XML должен быть динамически сгенерирован с автоматическими предложениями слов для данного пользователя на основе информации, введенной этим пользователем в базу данных.

В зависимости от приложения, которое вы пытаетесь создать, может быть проще выполнять полнотекстовые SQL-запросы к определенным полям базы данных. Для повышения производительности вы, вероятно, могли бы создать файл cookie, который будет кэшироваться браузером клиентов, и ваше приложение будет проверять наличие изменений или проверять, существует ли он, прежде чем выполнять полный запрос к базе данных.

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

Чак хотел бы знать, нужно ли вам что-нибудь еще, прежде чем он выдаст мой мозг.

person RJ Russell    schedule 05.02.2009
comment
Бьюсь об заклад, ты самый слабый человек на этой доске... :) - person naspinski; 05.02.2009