Здравствуйте, <Аноним>, Вы писали:

А>Здравствуйте, dimzon, Вы писали:

D>Здравствуйте, bmv, Вы писали:

bmv>>В таблице 240000 записей, причем каждая является уникальной (как я уже говорил, перечень деталей).
D>И что, они все будут удовлетворять условию поиска?
D>И второй вопрос, что пользователь будет делать с такой необъятной таблицей? Глазами нужную искать? Повторюсь — ЗАДУМАЙТЕСЬ О ХОРОШЕЙ ФИЛЬТРАЦИИ, ДАВАТЬ ПОЛЬЗОВАТЕЛЮ ТАКУЮ ПРОСТЫНЮ ЭТО МАРАЗМ
А>Я с этим согласен, пользователю все это не нужно... Только я не могу понять, как будет в Вашем случае интерфейс пользователя выглядеть. Вот пользователь открывает окно и...

---------------------------------------------------------------
| Здесь поля фильтра и кнопка "Обновить"                      |
---------------------------------------------------------------
|                                                             |
| Здесь злосчастная таблица. При открытии вместо нее надпись: |
|  Заполните фильтр и нажмите обновить                        |
|                                                             |
| При  отсутствии данных, удовлетворяющих фильтру надпись:    |
|  "Не найденно ни одной записи, удовлетворяющей условию"     |
|                                                             |
---------------------------------------------------------------

А>Однако здесь он может задать такой фильтр, который нас и не спасет вовсе от большого списка.
Надо искуственно ограничить размер выборки скажем 500-и строк. Тогда пишем такой запрос:

SET ROWCOUNT 501
SELECT ... И понеслась...
SET ROWCOUNT 0

И смотрим сикоко строк вернулось, если 501 то все равно показываем 500 и где-нить на форме выводим предупреждение: "Показаны первые 500 записей. если надо что-то конкретное ужесточите условия поиска"

D>Гы. Простая математика. Пусть у нас есть искуственный первичный ключ IDENTITY. В памяти один первичный ключ занимает 4 байта. (240000 * 4)/1024=937,5 килобайт < 1Мб.
D>Почему нельзя это счастье забрать на клиетна, разве один мегабайт это так много?
А>Подсчет конечно верный, только что нам дает хранение этого счастья? Кроме занимаемого 1 Мб ОП (который отнюдь не лишний), по-моему, ничего. Как правило данные отображаемые пользователю отсортированы вовсе не по колонке IDENTITY. И вообще, зачем хранить полный список, если у отображаемой нами порции данных всегда можно узнать начальный ключ и конечный ключ и, соответственно, загрузить следующую необходимую порцию.
Ну во первых можно получить список идентификатров уже отсортированный как надо (select ProductID from dbo.Product order by ProductName), Во вторых это "облегчает" выполнение повторных запросов, ведь фильрация может быть далеко не тривиальной, а так один раз уже отфильтровано и при повторных запросов поиск происходит просто по значению первичного ключа что для SQL расплюнуть.