Сортировка даных в Dbgrid

Вот команда которая сортирует даные в таблице от первой (верх таблици) до последней (низ таблици): DataModule1.main_table.IndexFieldNames:='id';
а как сделать что бы сортировка происходила от последне (верх таблици) к первой (низ таблици)
Сделать еще индекс с обратной сортировкой и активировать его.
Цитата(DZX @ 1:02:2007, 09:56 )
Нужно создать индекс со свойством Descent.
Если используется ADO то проще и быстрее воспользоваться свойством Sort задав там список полей для сортировки помечая их ASC или DESC (прямая и обратная сортировка)
Код
Подход описаный в последнем посте подходит только для небольшого кол-ва записей т.к. по времени данный способ примерно соответствует построению того же самого DESC индекса.
Данный подход применялся как раз для большого числа записей.
Хоть это теоретически и не очевидно, но исходя из личного практического опыта :
если информации много то пересортировать локальный DataSet гораздо быстрее чем перезапросить с сервера набор данных с другим индексом. Это так же вытекает из принципа работы ADO т.е. отсоединенный режим. И крутить - вертеть данные локально по любому быстрее.
Батенька! Сервер или БД у Вас ДЕРЬМО! Локально, с учётом большого кол-ва записей никогда не бывает быстрее не теоретически не практически.
У вас быстрее RAM закончится чем вы 1 000 000 пересортируете локально. Это Бред!
Клиент-серверные технологии для того и созданы, что бы отдать на откуп серверу, который, кстати, должен быть мощнее в десятки раз рабочих станций, основную часть рутинной работы.
BDE и ADO выигрывают в локальных операциях, пока память под кэши не закончится, а дальше туши свет, сливай воду...
Я не могу судить о всех реализациях разных БД. Но в теории сортировка одна из самых ресурсоёмких задач для БД. И сказя вкупе с усиленной шиной и быстрой памятью и многопроцессорностью, как нельзя лучше подходят для наиболее быстрой сортировки. А если учесть, что юзверь всё равно не сумет объять все данные сразу, то порционная выдача отобранных данных относительно курсора ещё убыстрит процесс.
Скорее всего не все промышленные БД реализованы грамотно, но думаю, что большинство.
Сообщение отредактировал LAW - 16:02:2007, 13:04
1. По поводу ДЕ..МА и Бреда - Очень аргументированно, эмоции это хорошо, но не то место и время.
По делу:
К сожелению на просторах СНГ ситуация с хорошим сервером и толстым каналом исключение,
а не правило. И разговора бы небыло, но реалии дело куда более невеселое. Ну что же
делать ребятам если и сервер уних( не культурно но метко вы выразились выше), ну
и сетка туда же, а информации вагон, а автоматизироваться хотят, а денег не дают ...
Вот и изголяемся...
Вторая часть вашего поста несет больше конструктивных идей. Все знать нельзя.
По поводу механизмов BDE и ADO спорить не будем, много эмоций, я думаю каждый
желающий сам прочитает теорию.
Ну мож немного и погорячился , но когда использовал BDE или ADO по своему алгоритму.
100 000 записей обрабатывались за 2 сек.
400 000 записей за 8 сек.
а 1 000 000 отрабатывался 4 мин. с ужасным хрустом винта, а то и полным зависанием приложения.
Как перешёл на сервер с прямыми компонентами всё выравнялось.
100 000 - 5 сек.
400 000 - 20 сек.
1 000 000 - 50 сек.
Вот и ответ был для меня.
Получается, что совершенно непредсказуемо на каком кол-ве записей произойдут проблемы.
Сообщение отредактировал LAW - 17:02:2007, 09:24
Бывает ,
Я еще раз проанализировал информацию(типа НЛП, коллега посещает
курсы муть конечно, но некоторые идеи интересны) и пришел к выводу
что мы говорим о разном. Т.е. каждый прав т.к. в вашем случаи
много информации которую нужно пересортировать, а в моем просто много.
Т.е. пересортировывать нужно не много.
Пример: на сервере лежит 3-4 миллиона записей, по фильтру юзер
видит сотню от силы и хочет ее сортировать вдоль и поперек,а
так как выборка фильтра довольно сложная, то каждое обращение к серверу за
такой малостью очень болезненно происходит и вот в этом случае
очень хорошо работает описанный мною способ.
В вашем случае на 100% принимаю пусть делает сервер.
Да. Прочитав Ваше сообщение я тоже это понял. И принимаю Вашу точку зрения по этому вопросу.
Хочу только отметить, что Вашем методе сортировки локально, лучше прямо в запросе ограничить кол-во возможных отобраных данных примерно 100 000.
Много раз встречал моменты, когда планируешь, пишешь, тестируешь, всё ок. Как юзверь садится, так такие перлы вылезают Что запрос, который и в приннципе-то не должен более 10 000 отбирать, черег годок отбирает лям и больше.
e меня на форме 6 компонентов: DataSource, Table, DBGrid, DBNavigator, ClentDataSet, DataBase. подскажите как отсортировать даніе в DBGrid (только не очень заумно). заранее благодарен!!!