Согласен с FomPro. Вываливать на экран нужно такое количество информации, которое пользователь морально готов прочитать. Если же он заведомо не собирается читать содержимое 100000 записей, значит они ему не нужны, и поток данных должен быть ограничен по какому-то критерию, который должен быть задан перед выборкой.

Для решения данной проблемы существует несколько путей.
1. Использование серверных курсоров.
2. Использование древовидных справочников с динамической подгрузкой в TreeView только тех частей дерева, которые нужны пользователю. Иерархическая организация данных как раз и позволяет разбить большой массив информации на части, которые хочет отобразить у себя пользователь.

> Скажите, Garya, где об этом можно подчитать?
На данном форуме, например ... А можно просто пораскинуть мыслями по полочкам.

>как то не очень понимаю причем здесь деревья?
Представьте себе орго-о-о-о-мный номенклатурный справочник. Записей на 10000000000 .
Пользователи сами организуют его в виде дерева. На первом уровне - номенклатурные группы (например, виды товарных групп - кабельная продукция, услуги, металлопрокат, ГСМ, насосное оборудование), на втором - подгруппы (например, по видам торговли имортные / экспортные / СНГ-шные), на третьем подподгруппы (например, для насосного оборудования - по областям применения - бытовые насосы, химические, фекальные, для перекачки абразивных смесей, для перекачки нефти и газа) и т.д. до 10 уровней иерархии. А теперь представь, что ты открываешь этот справочник, но тебе отфильтровалось только 10 записей самого верхнего уровня (а не 10000000000). Далее ты щелкаешь по плюсику возле ноды "насосное обрудование" в TreeView чтобы развернуть содержимое данной папочки. Тут же на сервер идет запрос и автоматом подкачиваются еще 10 записей второго уровня, дочерних для кликнутого узла. Потом еще 10 записей третьего уровня после третьего клика... и т.д. При каждом клике подгружается только 10 записей. А ежели дерево хорошо сбалансировано, то 10 кликами идя по иерархической структуре ты достаточно быстро доберешься до нужного листа дерева, ибо при условии хорошей сбалансированности дерева как раз указанное количество записей (10000000000, то есть 10 в 10 степени) позволяет выбрать визуально из всего этого огромного массива данных нужную запись, подгрузив с сервера всего 100 записей (за все 10 кликов вместе взятых). Конечно, кликать 10 раз муторно, но это гораздо менее муторно, нежели глазами прошаривать одну огромную таблицу с 10000000000 записей, предварительно неделю дожидаясь ее загрузки с сервера.

Отдельно зачесалось высказаться по последнему категоричному постингу Cube:
>1. Загружать на клиента все записи недопустимо. Это аксиома.
Интересно, кто ее автор? Павел привер хороший пример, когда эта аксиома не работает. MS разработала ADO.NET, в которой активно использует буферизацию на клиенте не только данных, но и бизнес-логики сервера (для того, чтобы буферизация смогла эффективно работать), практически доведя эти механизмы до уровня репликации, только не между сервером и сервером, а между сервером и клиентом. Или ты полагаешь, что MS - заблудшая овца?
>6. Возражения Borland-фанатов не принимаются
А не фанатов? А просто программистов? Которые привыкли не изобретать уже изобретенный велосипед? А тот так можно дойти и до SQL-сервера собственного производства...

>СКУПОЙ ПЛАТИТ ДВАЖДЫ, Павел. Тем более, с таким подходом "потом переписывать" придется уже не Вам =)
Уж не метите ли вы на его место ? Или вы ученик Нострадамуса, и заранее предвидите его увольнение?
У каждого подхода есть плюсы и минусы. Можно сначала достаточно быстро разработать приложение, заранее предусмотрев в нем пути дальнейшей доработки. И производить эти доработки после того, как приложение начало крутиться (пусть и не в идеальном виде) и приносить пользу. А можно очень долго клепать идеальный продукт, и так никогда его и не склепать. А вы сами пробовали реализвать WEB-интерфейс для продукта средней паршивости, завязанного на учетные задачи? Как вы полагаете, во сколько раз разработка такого интерфейса дольше во времени, нежели при использовании RAD того же Borland-а, которого вы так ненавидите? Или того же Access?

Я подразумевал дерево, которое лежит в фиксированном количестве таблиц (например, в одной). Тогда его дальнейшее разветвление, расширение и углубление производится самими пользователями без внесения изменений в текст запросов.
А вот ежели помещать группы в одну таблицу, подгруппы - в другую, подподгруппы - в третью... и т.д., то когда поднадобится гденибудь что-нибудь ответвить в глубину, придется создавать дополнительную таблицу. Нет, я не берусь утверждать, что такая структура не имеет права на существование. Конечно же имеет. Но тогда, когда структура иерархии заранее известна и неизменна.
То, что древовидные структуры не свойственны реляционным инструментариям, тоже не спорю (кстати, это тоже обсуждалось). И уже высказывалось мнение по поводу того, что всю окружающую действительность невозможно подпихнуть ни под реляционную, ни под иерархическую, ни даже под сетевую модель. Всегда чего-то не хватает. Мне приходилось в древности ковыряться с иерархической СУБД MUMPS - там изворачивались вокруг таблично-подобных представлений данных. В иерархических изворачиваются вокург иерархических (ситема меню, например, древовидные справочники и т.д.). В сетевой есть проблемы простоты адресации к объектам и сложность языковых средств инструментария (почему данные системы еще меньше распространены, нежели иерархические).
А для желающих ссылочка по деревьям в реляционной среде (правда, на данном форуме она уже фигурировала и не раз): http://sdm.viptop.ru/articles/sqltrees.html