Отображение результатов поиска в ListView, когда количество символов больше 3 в WinForms

Question

У меня есть простой ListView с 3-4 столбцами, которые отображают список клиентов. Ниже есть TextBox, который используется для поиска в Sql Server и отображения связанных результатов (в основном он выполняет sql query каждую отдельную букву при вводе. Он отлично работал с небольшим количеством клиентов, но при наборе одной буквы более 1000 удерживает его отображать в течение нескольких секунд, отображать множество записей, затем еще одну букву сделать немного быстрее, а затем еще одну ...

Итак, я подумал о нескольких возможных исправлениях:

• Начать поиск после ввода 3 букв (имя имеет не менее 3 символов), ничего не делать для 1-й / 2-й буквы и отображать все для 0 (тем не менее задержка при возврате из поиска)
• Загрузите список один раз в List<string> или создайте какой-либо объект, чтобы покрыть это, но мне нужно было бы синхронизировать его с любыми изменениями, которые делают другие пользователи (добавление новых клиентов, обновление имен и т. Д.) Из другой работы. места и всегда обновлять список с правильной информацией. Поддерживать связь с базой данных кажется более простой идеей.
• Другие идеи? Может быть, сочетание обоих?

Вот пример кода:

   private void klienciSearchBoxTextChanged(object sender, EventArgs e) {
        string varSzukaj = klienciSearchBox.Text.Trim();
        if (varSzukaj.Length >= 3) {
            pobierzDaneSqlKlientaOgolne(listViewKlienci, lvwColumnSorterKlienci, varSzukaj, radioButtonWyszukajPoPortfelu.Checked ? 1 : 0);
        } else if (varSzukaj.Length > 0 &&  varSzukaj.Length < 3) {
            // do nothing
        } else {
            pobierzDaneSqlKlientaOgolne(listViewKlienci, lvwColumnSorterKlienci, varSzukaj, radioButtonWyszukajPoPortfelu.Checked ? 1 : 0);
    }

Достаточно ли хороша первая или вторая идея или кто-то может предложить другую реализацию?

Answer 1

Тип дизайна интерфейса, который вы используете в настоящее время для поиска, лучше подходит для данных, которые обновляются редко. Например, скажем, у вас есть список из 10000 продуктов, которые обновляются раз в неделю, в этом случае кэшируйте данные локально, а затем извлекайте данные из кэша вместо базы данных для каждой набранной буквы. Таким образом, это один запрос к БД, а затем множество запросов к локальному кешу.

В вашем случае обновления данных встречаются чаще, поэтому я бы изменил интерфейс, чтобы пользователи могли вводить некоторые буквы, а затем нажимал кнопку поиска, когда они готовы получать результаты. Как отмечает JamesB, ограничение результатов также поможет, но вы по-прежнему попадаете в базу данных с большим количеством запросов. Если пользователи могут жить с некоторой задержкой данных, кэширование может быть вариантом. В базе данных много бесполезного поиска: «M», «Ma», «Mad», «Madb» и так далее ...

Answer 2

В аналогичной ситуации мы справились с этим, ограничив количество результатов, которые пользователь может получить обратно. Мы использовали ограничение в 500, чтобы все было быстро, и запустили запрос подсчета перед выполнением запроса выбора, чтобы проверить, не собирается ли программа приостановить работу программного обеспечения.

Это также зависит от того, является ли проблема неотзывчивым пользовательским интерфейсом или ожиданием пользователя. Поскольку неотвечающий GUI можно исправить, запустив запрос в отдельном потоке, вы можете проверить, выполняется ли запрос и отменить его, когда пользователь введет следующую букву. Другим вариантом предотвращения ожидания пользователя будет отображение частичных результатов.