Я тока учусь, поэтому придумываю для себя всякие отфонарные задачки - вы уж не ругайтесь...
Задача:
Одна таблица, из которой делаются выборки клиентским приложением с условием по одному-двум-трем полям (т.е., задается либо одно поле либо два, либо три). Записей - более 60 тыс.
Возможна ситуация, когда (особенно при поиске с условием по одному-двум полям) возвращается большое количество записей. Человеку, который сидит за компом - надобна только одна, и если возвращается более нескольких десятков записей, он просто не будет заморачиваться с поиском глазами по списку, а уточнит запрос. Получается, в данном случае выполнение запросов, возвращающих слишком большое количество записей просто не нужно, да и вредно - зачем прокачивать по шлангу несколько сотен записей, ежели человек их проигнорирует?
Идея:
Перед выполнением запроса оценить количество возвращаемых записей и сообщить его программе-клиенту, а она, сравнив его с неким значением, решала бы, выполнять запрос, или нет.
Вопрос:
Как это реализовать (интересует серверная часть)?

2Replicant:
В общем, Вы подтвердили мои мысли, вот они:
Две хранимые процедуры:
1.Считает количество записей по переданным в нее критериям.
(как, кстати это сделать? select count(*) from ... where ...?)
2.Возвращает записи по переданным в нее критериям.
Прога сначала вызывает первую, анализирует количество, и принимает решение - ругаться на юзверя, или вызывать вторую.
Кстати, можно и несильно ругаться, а предупредить его, что записей слишком много, и возвратить десяток-два первых, сказав об этом и посоветовав уточнить критерии.
Это верное решение? или существует более изящный вариант?

2Genady:
>Вероятно вопрос возник именно из-за того, что задача отфонарная
>......
>просто в where у вас будут более строгие ограничения и не надо будет оценивать сколько записей возвращает запрос

Ну, скажем, не совсем отфонарная (я бы сказал, несколько упрощенная )
Долго думал, какой бы пример привести, и наконец придумал!
Допустим, из нескольких полей-критериев - 2шт. такие: ФИО и Улица.
К клиентскому приложению есть требование - максимальная скорострельность (помимо низкого трафика).
Тут мы сталкиваемся с проблемой скорости заполнения юзверем полей-критериев.
Юзверю всегда нужна только одна запись, причем мы имеем ввиду, что при заполнении десятка полей запроса он может где-нить и ощибиться, т.е., не получить вообще ничего.
Поэтому разрешаем ему пользоваться нечеткими критериями, вываливая ему некоторое количество записей, но ограничивая это количество - так как при нескольких десятках записей он просто убъет время, выискивая нужную...
Собственно, иллюстрация мысли:
Ну зачем, спращивается, заполнять десяток полей запроса для фамилии "Суньмуньввунь", если в лучшем случае, будет возвращена всего одна запись?
Или фамилия "Иванов". Без задания дополнительных критериев тут не обойтись, но и тут есть нюанс: в одном случае достаточно дополнительно задать улицу, если это переулок из нескольких домов, а в другом (Красный проспект в Новосибе, например ) - без заполнения доп. полей не обойтись.
И это я придумал пример, когда логика понятна и может быть отработана на уровне мозгов юзверя (т.е., если в голове - не кость, то и не нужно реализовать мой алгоритм)... А если нет?

Так что не все просто!
Не, я не спорю, но, может быть, в моих рассуждениях есть капля здравого смысла? Ну хоть капелька?
Ну а вообще-то, по большому счету, я согласен с Genady

Спасибо за ответы!

2Gennady:
>Есть, есть, не сомневайтесь
Это радует
>З.Ы. Пример некогда придумывать, так что сорри
Ничо страшного, предыдущей строчки достаточно

2Павел:
>Может я все сильно упрощаю
Да не, я ж такой вариант тоже рассматривал, напомню:
...а предупредить его, что записей слишком много, и возвратить десяток-два первых, сказав об этом и посоветовав уточнить критерии.

2Glory:
Не совсем понял, как это все применить к моей задаче, но переспрашивать не буду - попробую почитать умные книги

2MadDog:
Вот! Попробую-ка я сделать оба варианта - вариант с возвращением части записей и последующей руганью и Ваш вариант (первый, однако,проще )

Спасибо за ответы!

2Garya:
Рад тебя слышать! Я c Access некоторое время уже завязал - теперь вот SQL мучаю (а также обитателей этой конфы) Все хотел тебе написать (пара махоньких вопросов есть), но не решался без разрешения. Можно? (на corbina или на chat?)

Сервер сначала выберет весь млн. записей, отсортирует его, отрежет TOP 10 и пошлет клиенту
Субж!!!
А как же тогда быть?
Получается, минимизируем сетевой трафик, но грузим сервак?

2Dmitry:
Спасибо огромное за информацию. Сначала напугался, потом, при здравом размышлении, понял, что по другому и не должно быть в случае с сортировкой. Буду иметь ввиду. Хотя, для поставленной задачи, это и не очень актуально - здесь порция записей используется, в основном, для демонстрирования юзверю титанических усилий проги по добыче информации
И еще.
Если у меня в запросе все критерии делаются по индексированным полям, то так ли уж нужна сортировка, ведь, по идее, набор должен быть упорядочен в соответствии с индексами?

А вот вариант с интернет-liked решением. Т.е., есть грид с порцией записей, под ним пара кнопок "назад" - "вперед" (либо список типа 1-10, 10-20, 20-30...., динамически заполняемый в зависимости от числа записей). Каков алгоритм работы проги по добыванию порции, например, с 10 по 20 запись? Интересуют именно запросы к серверу, т.е., вместо TOP что-то вроде {from 10 to 20}. Такое возможно без лишних телодвижений (и доп. нагрузки на сеть/сервер)?

ЗЫ: забавно, но несколько лет работы с Access задавался вопросом - нафига нужна эта фича - "TOP", т.е., не представлял себе реального применения, и на тебе, столкнулся

2Axl_Dead:
Угу, спасибо, поясняю: VB6 (в котором я тоже не очень - на стадии перехода от Access97, так что не ругайте за глупость).
Так что ASP не подходит, а Ado'шный рекордсет вроде не бьется на страницы...(?)

Тем не менее, как-то ведь это сделано в Access2000 (.adp)?????
Более того, там в табличной форме этот алгоритм еще красивее сделан: с сервака пересылается только кусок результирующего набора записей, а когда юзверь скроллится к его концу, у сервера запрашивается следующий кусок и т.д. Все делается прозрачно для пользователя. Беда только в том, что весь этот механизм зашит глубоко в недрах Access, и как написать подобную форму в VB мне непонятно...
Извините, если гонЮ - с Acc2k знакомство поверхностное - решил не вникать, взявшись за VB...

Классно! Из ламерского вопроса такая интересная (для меня, по крайней мере ) дискуссия вышла!!!

2Vladimir: Топик длинный, и, видимо, к середине уже теряется нить. Вкратце:
Из чего складывается время поиска инфы?

1.Забивка юзверем полей-критериев.
2.Обработка запроса сервером и получение инфы с сервака
3.Идентификация юзверем необходимой записи, если возвращено много (напомню, юзеру нужна только одна запись, причем ее определяют однозначно полная комбинация критериев отбора).

Так как полей отбора много, то идем на поблажки, дабы минимизировать п.1, разрешая не заполнять все поля (имея при этом ввиду, что может быть запрос по неполным исходным данным).
Если записей возвращается много, то просмотр юзверем всех возвращенных записей, чтобы найти искомую, напрочь съедает выигрыш, полученный в п.1, увеличивая и время выполнения п.2
Для этого и нужно все, что здесь обсуждается - возвращаем несколько записей, и просим уточнить критерии. Юзер заполняет еще одно-два-три поля (по ситуации), и получает искомое.
Меня можно спросить - а не будет ли юзер постоянно уточнять поиск? Анализ моей базы позволяет оценить эту вероятность в 10-15%, т.е., для получения удобоваримого количества записей (7-10) в 85-90% случаев достаточно 1-2-х полей из 5...
К сожалению этот процент уменьшается из-за того, что по придуманным мной условиям задачки, поиск идет по Like 'блаблаб%', а не по =

>но как быть если юзер хочет "быстрый" поиск, т.е. нажал "б", когда находится в поле ФИО, встал на ближайшую запись, которая начинается на "б", потом нажал на "а", встал на ... "ба" и т.д.
А вот в этом вопросе я титан
Здесь - задача программиста - убедить юзверя, что это не есть гуд! и все дела!
Этот вариант годится для несетевого приложения и на небольших объемах (ИМХО) - вываливаем на форму всю базу, на поле ФИО вешаем обработчик события Change, в которой делаем текущей записью первую, удовлетворяющую условию из поля, например, "Ивано*". В Access - это как два пальца об асфальт...
В принципе, годится он и для моей задачи: Выборку делаем по 2-м самым важным полям, а на остальные поля - вешаем "быстрый поиск" уже по возвращенному набору. Но этот вариант не удовлетворяет условию из субжа!

2Axl_Dead:
Спасибо огромное за пример, буду RTFM

>А вот что пролистав страницу до конца, придется некоторое время сидеть с пустым экранном - это не так ясно.
А вот тута можно выкрутиться:
Допустим, на форме помещается 10 записей. Делаем пакет длинной в 30 записей. Для упрощения примем, что юзверь смотрит самые первые и начинает скроллиться вниз. Скроллинг идет с довольно медленной скоростью (с точки зрения компа). Отслеживаем, когда при прокрутке вниз нижней записью становится 20-я, и в этот момент подсасываем с сервака следующий пакет! Пока он доскроллится до конца первого пакета, второй уже тут-как-тут!!! Размер пакета и позицию начала подсоса следующего мона подобрать экспериментально...
Так что проблемы-то и нет. Точнее, проблема в реализации... Может, мне стоит поковырять поплотнее VB?