Привет!
1.
2.
3.
4.
5.
Вопрос такой возник:
У пользователя на экране в табличке показан прайс
(примерно 40000 наименований). Пользователю надо из этой таблички что-нибудь выбирать (т.е. курсором,
потом Enter нажать и т.п.).
Как в таком случае запрашивать с сервера НЕ ВСЕ ЗАПИСИ ИЗ
ЭТОЙ ТАБЛИЧКИ, а только те, которые нужно на экране показать???
Вот именно про такой случай я и писал. Если загружать все 4000 на клиента путем DataSet.Open, DataSet.Last, то BDE будет вне конкуренции - очень быстро.
А для native библиотек подход примерно такой.
- Пользователь 4000 записей сразу просмотреть не может, так?
- Поэтому надо выводить меньше записей.
- Чтобы выводить меньше записей, надо уточнить условия.
Уточнение условий может быть двух видов - либо уточнение предметных условий, либо псевдо-уточнение - просто ограничение вывода.
Уточнение предментых условий.
Этот вариант является истинно SQL-евским, но пользователи, привыкшие к огромным листам EXCel, его плохо переносят (но переучивание возможно :).
Когда пользователь ищет какой-то товар, надо попросить его сначала ввести первые буквы наименования, категорию товара, или ограничение по цене или еще что-то в этом роде, и потом выполнить запрос вида:
1.
2.
Select *
from table t
where t.product_name starting with 'Motoro' And t.price< 100
при этом выйдет гораздо меньшее число записей.
Псевдоуточнение
Это вебовский прием, который можно увидеть на любом сайте, где производится поиск.
Мы создаем запрос как нам будет угодно (в том числе можно использовать и первый способ, с предметными условиями), и затем добавляем туда следующую вещь:
1) Либо конструкцию SELECT FIRST <x> SKIP <y> .... для вывода первых x записей после пропуска y. (Это в Firebird, в IB конструкция выглядит как ROWS x TO y в самом конце запроса)
2) Либо, если у нас нет никакой сортировки при выборе, то можно воспользоваться первичным ключом и добавить в WHERE такое условие:
1.
2.
3.
4.
Select * from table t
where .....
and (
t.первичный_ключ >=y and t.первичный_ключ <=x+y
)
В том и другом случае мы получим ограниченный набор записей в 100 штук (ну или сколько душа пожелает).
Разумеется, эти x и y должны быть параметрами в запросе.
Далее, у пользователя появляется две кнопки
Страница вперед и
Страница назад , после нажатия на которые параметры запроса увеличиваются/уменьшаются на заданный шаг.
Также можно выполнить еще запрос с Count(), посчитать общее количество записей и вывести их для справки.
Как Вы уже поняли, лучше всего будет скомбинировать оба способа сразу - и вводить хоть какие-то предметные условия, и разбивать вывод постранично.
Недостатки способа:
1) Нельзя воспользоваться multi-select в grid. Это так, поэтому выбор товаров придется сдеать в стиле "корзины", когда кнопка
Добавить переносит выбранный товар в другой ДатаСет.
2) Пользователь может захотеть "гладкий скроллинг", без всяких кнопок. В сущности, можно сделать отслеживание положения курсора в гриде и вызывать нужный запрос при приближении к концу, но не стоит - лучше убедить пользователя в целесообразности поэтапного вывода. Кроме того - см. достоинство N.3
3) Больше кодирования. Да, хорошо было в БДЕ - бросил грид, написал Table.open и все заработало... Но надо четко понять, что таким способом написать приложение для большого массива данных нельзя. По воробьям и слонам стреляют из разных ружей.
Достоинства:
1) Очень быстрая работа и малая нагрузка сервера. Если есть все нужные индексы, то запрос на выборку выполняется моментом, а сервер при этом почти не загружен.
2) Масштабируемость. Такой подход будет работать и на 4000 записей, и на 4000000. Разница будет незаметна.
3) Легкий переход на веб-решение. Если вдруг начальство захочет выводить прайс лист на веб-сайте с возможностью поиска, то те же самые запросы и механизмы можно будет легко прикрутить к веб-решению.
4) Все правильные пацаны делают так )))
С уважением,
Алексей.
