• 15 апреля стартует «Курс «SQL-injection Master» ©» от команды The Codeby

    За 3 месяца вы пройдете путь от начальных навыков работы с SQL-запросами к базам данных до продвинутых техник. Научитесь находить уязвимости связанные с базами данных, и внедрять произвольный SQL-код в уязвимые приложения.

    На последнюю неделю приходится экзамен, где нужно будет показать свои навыки, взломав ряд уязвимых учебных сайтов, и добыть флаги. Успешно сдавшие экзамен получат сертификат.

    Запись на курс до 25 апреля. Получить промодоступ ...

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

  • Автор темы VahaC
  • Дата начала
V

VahaC

Вот команда которая сортирует даные в таблице от первой (верх таблици) до последней (низ таблици): DataModule1.main_table.IndexFieldNames:='id';
а как сделать что бы сортировка происходила от последне (верх таблици) к первой (низ таблици)
 
D

DZX

Сделать еще индекс с обратной сортировкой и активировать его.
 
L

LAW

Нужно создать индекс со свойством Descent.
 
D

DZX

Если используется ADO то проще и быстрее воспользоваться свойством Sort задав там список полей для сортировки помечая их ASC или DESC (прямая и обратная сортировка)

Код:
TADOQuery.Sort:="FirstField ASC, DateDue DESC";

Если используется связка BDE - ODBC то проще при создании таблицы создать необходимые индексы и после в программе их выбирать.
 
L

LAW

Подход описаный в последнем посте подходит только для небольшого кол-ва записей т.к. по времени данный способ примерно соответствует построению того же самого DESC индекса.
 
D

DZX

Данный подход применялся как раз для большого числа записей.
Хоть это теоретически и не очевидно, но исходя из личного практического опыта :
если информации много то пересортировать локальный DataSet гораздо быстрее чем перезапросить с сервера набор данных с другим индексом. Это так же вытекает из принципа работы ADO т.е. отсоединенный режим. И крутить - вертеть данные локально по любому быстрее.
 
L

LAW

Батенька! Сервер или БД у Вас ДЕРЬМО! Локально, с учётом большого кол-ва записей никогда не бывает быстрее не теоретически не практически.
У вас быстрее RAM закончится чем вы 1 000 000 пересортируете локально. Это Бред!
Клиент-серверные технологии для того и созданы, что бы отдать на откуп серверу, который, кстати, должен быть мощнее в десятки раз рабочих станций, основную часть рутинной работы.
BDE и ADO выигрывают в локальных операциях, пока память под кэши не закончится, а дальше туши свет, сливай воду...

Я не могу судить о всех реализациях разных БД. Но в теории сортировка одна из самых ресурсоёмких задач для БД. И сказя вкупе с усиленной шиной и быстрой памятью и многопроцессорностью, как нельзя лучше подходят для наиболее быстрой сортировки. А если учесть, что юзверь всё равно не сумет объять все данные сразу, то порционная выдача отобранных данных относительно курсора ещё убыстрит процесс.
Скорее всего не все промышленные БД реализованы грамотно, но думаю, что большинство.
 
D

DZX

1. По поводу ДЕ..МА и Бреда - Очень аргументированно, эмоции это хорошо, но не то место и время.
По делу:
К сожелению на просторах СНГ ситуация с хорошим сервером и толстым каналом исключение,
а не правило. И разговора бы небыло, но реалии дело куда более невеселое. Ну что же
делать ребятам если и сервер уних( не культурно но метко вы выразились выше), ну
и сетка туда же, а информации вагон, а автоматизироваться хотят, а денег не дают ...
Вот и изголяемся...

Вторая часть вашего поста несет больше конструктивных идей. Все знать нельзя.
По поводу механизмов BDE и ADO спорить не будем, много эмоций, я думаю каждый
желающий сам прочитает теорию.
 
L

LAW

Ну мож немного и погорячился :) , но когда использовал BDE или ADO по своему алгоритму.
100 000 записей обрабатывались за 2 сек.
400 000 записей за 8 сек.
а 1 000 000 отрабатывался 4 мин. с ужасным хрустом винта, а то и полным зависанием приложения.
Как перешёл на сервер с прямыми компонентами всё выравнялось.
100 000 - 5 сек.
400 000 - 20 сек.
1 000 000 - 50 сек.

Вот и ответ был для меня.
Получается, что совершенно непредсказуемо на каком кол-ве записей произойдут проблемы.
 
D

DZX

Бывает :),
Я еще раз проанализировал информацию(типа НЛП, коллега посещает
курсы муть конечно, но некоторые идеи интересны) и пришел к выводу
что мы говорим о разном. Т.е. каждый прав т.к. в вашем случаи
много информации которую нужно пересортировать, а в моем просто много.
Т.е. пересортировывать нужно не много.
Пример: на сервере лежит 3-4 миллиона записей, по фильтру юзер
видит сотню от силы и хочет ее сортировать вдоль и поперек,а
так как выборка фильтра довольно сложная, то каждое обращение к серверу за
такой малостью очень болезненно происходит и вот в этом случае
очень хорошо работает описанный мною способ.
В вашем случае на 100% принимаю пусть делает сервер.
 
L

LAW

Да. Прочитав Ваше сообщение я тоже это понял. И принимаю Вашу точку зрения по этому вопросу.
Хочу только отметить, что Вашем методе сортировки локально, лучше прямо в запросе ограничить кол-во возможных отобраных данных примерно 100 000.

Много раз встречал моменты, когда планируешь, пишешь, тестируешь, всё ок. Как юзверь садится, так такие перлы вылезают :) Что запрос, который и в приннципе-то не должен более 10 000 отбирать, черег годок отбирает лям и больше.
 
V

Vovandocka

e меня на форме 6 компонентов: DataSource, Table, DBGrid, DBNavigator, ClentDataSet, DataBase. подскажите как отсортировать даніе в DBGrid (только не очень заумно). заранее благодарен!!!
 
M

miha4406

Пытаюсь написать сортировку кликом по тайтлу столбца.
-----
procedure TfmMain.dbgPatTitleClick(Column: TColumn);
begin
dmRay.ibdsPat.sort:=column.field.fieldname+' ASC';
end;
-----
пишет:
undeclared identifier 'sort'

чего не хватает? или как по-другому написать? БД - Interbase
 
M

miha4406

Так и как его задеклорировать? Что это ваще д.б.? Это не мой код.
 
E

etc

Откуда тут знают что за дб у вас, можно догадаться, что либо интербейз либо файерберд.
Раз код не ваш, чего трогаете?
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!