Расширитель автозаполнения Ajax, заполненный из SQL
Хорошо, сначала позвольте мне заявить, что я никогда не использовал этот элемент управления, и это также моя первая попытка использовать веб-службу.
Моя дилемма заключается в следующем. Мне нужно запросить базу данных, чтобы вернуть определенный столбец и использовать его для автозаполнения. Очевидно, я не хочу, чтобы запрос запускался каждый раз, когда пользователь вводит другое слово в текстовое поле, поэтому лучше всего выполнить запрос один раз, а затем использовать этот набор данных, массив, список или что-то еще, чтобы затем отфильтровать расширитель автозаполнения .. .
Я вроде как потерял какие-либо предложения ??
Ответы 4
Этот вопрос зависит от того, насколько транзакционным является ваше хранилище данных. Очевидно, что если вы ищете штаты США (набор данных, который не будет реально меняться в течение жизни приложения), я бы либо кэшировал тип System.Collection.Generic List <>, либо если вам нужен DataTable.
Вы можете легко настроить кэш данных, которые вы хотите запрашивать, чтобы они зависели от XML-файла или базы данных, чтобы ваш расширитель всегда запрашивал объект данных, отлитый из кеша, а объект кеша обновлялся только при изменении источника данных.
Почему бы не отслеживать запрос, выполненный пользователем, в переменной сеанса, а затем использовать это для фильтрации любых дальнейших результатов?
Уловка для предотвращения перегрузки базы данных, я думаю, на самом деле состоит в том, чтобы просто ограничить частоту обновления автообновления, что-то вроде одного раза в 2 секунды кажется мне разумным.
Я бы сделал следующее: сохраняю текущий список, возвращаемый запросом, для слова A на стороне сервера и привязываю его к переменной сеанса. Я думаю, это должен быть в основном весь список. Затем для каждого нового введенного слова, пока существует исходное слово A, вы можете фильтровать информацию о сеансе и выводить отфильтрованные результаты без повторного запроса. Итак, в основном, запрашивайте снова только при изменении слова A.
Я использую «сеанс» в смысле PHP, вы можете использовать другой язык с другой терминологией, но концепция должна быть такой же.
Я большой поклонник сериализации объектов и их хранения как сессионных переменных. Но сеанс был бы хорош только в том случае, если бы запрос был специфичным для пользователя. Если бы это было приложение для всего приложения, вы бы получили избыточные данные, хранящиеся для каждого запроса.
Оперативная память дешевая, а SQL сложнее масштабировать, чем IIS, поэтому кешируйте все в памяти:
- весь ваш источник данных, если нет слишком большой, чтобы загрузить его в разумные время,
- предварительно рассчитанные данные,
- автозаполнение ответов веб-сервиса.
В зависимости от желаемого поведения и производительности автозаполнения может потребоваться предварительный расчет данных и создание избыточных структур, оптимизированных для чтения. Используйте такие структуры, как SortedList (когда вам нужно что-то вроде 'select top x ... where z like @query +'% '), Hashtable, ...
Хотя кеширование всего, безусловно, является хорошей идеей, ваш вопрос о том, какую структуру данных использовать, - это проблема, на которую здесь не дан полный ответ. Лучшая структура данных для расширителя автозаполнения - это Trie. Вы можете найти хорошую статью о .NET и код здесь.
любая помощь по веб-сервисам тоже будет полезна