Opilki_InsideСуществует ли класс....с локальным фильтром, сортировкой данных, и некоторыми другими фичами......... а может написать? кто-нибудь хочет присоединиться?

вдумайтесь....
база данных... и локальная сортировка...
тут рождаються варианты...
1) сменить БД
2) выкинуть БД
3) пойти попить пивка...отдохнуть...посмотреть на небо - оно очень красиво...на крайний случай к любимой девушке :)

мона глупый вопрос... нафига ?


удачи Вам
(круглый)

Opilki_Inside....зделали мы запрос, вытащили 10000 строк, теперь хотим побыстрому отфильтровать или отсортировать полученные данные, каждый раз запрос делать? Да дело даже не в фильтре или сортировке, а например локальный поиск по запрошенным данным организовать... или еще какие-нибудь удобные функции.......


я не знаю как в делфи... предлогаю включить разум...и операться на него...
пущай будет 10000 строк (хотя мне неясно - нахрена ?)...
а) Отфильтровать...я правильно понимаю...это пробежать по всем 10000. сравнить методом компаре (про приведения к формату не забываем)... что катит засовываем куда-то, аллокируя память...
б) сортировка... (не буду вдаваться в тонкости, грубо) это пробежать 10000 раз и на каждом этапе сделать 8 сравнений и копирование (самый тяжёлый случай)... не забываем при сравнении приведение к формату...
в) поиск... пробегаем 10000 сравниваем, не забывая про форматирование...

минусы...
самому изобретать велосипед.. если напишешь или поюзаешь готовый - то не спать и думать..."а вдруг ребята из фирмы Postgre (а может и сам Oracle к примеру) - сделали быстрее сортировку и(или) сравнение" ?
Время... Система локальная не готова к ударным нагрузкам в ввиде резервирования памяти, хэширования или кэширования...
работа с копией данных, которые могут протухнуть в любую секунду. Тогда их цена резко уменьшаеться с каждой секундой...
гиморничать с извещением изменений либо тупой апдэйт по времни...
гиморничать с подкачкой или плавающего этого 10000 - вдруг в базе 10001 ?

плюсы...
вроде как всё под рукой... но вроде бы и как нет - ведь а вдруг протухло 2 секунды назад ?

теперь поговорим как по уму....(возмём показ в гриде или вьюшке)
1) Нафига Вам сканировать 10000 ? Всё показать ? Человек может оценить несколько сотен записей...всё...Печатать ? ээээээээ а откель бумага халявная и тонэр ? Значит идёт речь о КАДРЕ ! Кадре, который может смещаться (вдруг челдобрек побежит вниз ?). ЛЮБАЯ база, поддерживающая индексирование, Вам может предоставить кадр со смещением по индексу... Значит время на запрос-ответ несколько миллисекунд (включая перегон по сетке).
2) Я не думаю, что Ваша фамилия Oracle, Postgre или Btrieve (к примеру). Посему вряд-ли один человек откроет, что то сверх гениальное в алгоритмах сортировки, мат анализа и теории случайностей...Более того, время затраченное Вами на алгоритм (его нахождение, изучение, написание, отладку) будет бОльшим по сравнению ОТДЕЛОВ этих фирм занимающихся не один ГОД (!) ТОЛЬКО этим. Значит самопальный алгоритм ВСЕГДА (99,9%) уступает проффесиональному.
3) БД - это сервер приложения для родного агента(клиента) этой БД. Посему это ИДЕАЛЬНАЯ точка для анализа и разрешения таких ситуаций как запросы на чтение и изменения инфы. Т.е. информация реального времени, при распределённом доступе к ресурсу - БД.

Выводы делайте сами...
Раскажу только про решение из реальной жизни...
сервак приложения + btrieve (OS Novell). На клиенте просмотр списка из БД ввёлся кадром. В момент закачки выводился диаложек - плиз вэйт. Закачка производилась по времени (что то около 10 сек) и при сканировании клиентом вверх или вниз. Данного диаложка видно не было... Клиент мог изменить порядок сортировки (по индексам), сортировка по одному - результат тот же...мгновенно...если инфу кто то удалял - это было сразу видно на всех клиентах - мгновенно (с задержкой менее 10 сек)...

И ышо одно...
на Oracle... алгоритм показа такой-же... сканирование более чем по одному полю (смешенный, с различной сортировкой) - посему индексов НЕ было. Поля РАЗНОТИПНЫЕ, различными прижимами, подсветкой и условиями... кадр накачивался мгновенно (что делает честь ораклу кстати - SQL запросы там по несколько киллобайт)...правда под ораклом ессесвенно шла оптимизация запросов серьёзная...

с уважением
(круглый)
ЗЫ
Алгоритм накачки в общих чертах...сорьки - это своя разработка...Но основные идеи тут прозвучали...

Opilki_Inside.......хочу написать класс, который упросит работу с libpq путем добавления новых функций, которых там нет...с накачкой тоже конечно интересно, на сколько быстро она будет работать с постгресом на больших объемах около 1 млн. записей?

упращать на мой взгляд нуна ОБРАЩЕНИЕ к API. А не подменой того, что наработано фирмой...
на счёт быстроты - зависит от самого запроса, от кол-ва сортируемых полей, от типа полей, от доп. функционала (прижим, форматирование, подсветка) - если это статика (формируем на клиенте) то легче. Если динамика - то тяжелее. Одни из самых "тяжёлых" операций для Oracle (да думаю для любой БД) это distinct, линки к другим БД и хранимки. В первом случае - операция над всей выборкой (пускай локально на серваке, но над всей). А во втором - сервак узкое последовательное место доп. анализа. В третьих - понятно, чёрные ящики они и есть чёрные ящики... Первое - тут уж архитектура такая... А вот второе - пришлось с клиента держать коннекшенны. Так шустрее для кадра... Ну а хранимки переделать в сам SQL - оптимизатору легче оказалось. Но это всё уже специфика...


с уважением
(круглый)

Opilki_Inside.........правда не могу понять почему такую негативную реакцию вызывают функции локального поиска/фильтра/сортировки.. что в этом такого? ......всегда есть проблемы со специфичными функциями типа копирования данных или скоростью работы.......

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

-----
один товарисч...
2*2=4
другой товарисч...
а вот 3*2 - шесть... ведь не плохо...давайте 2*2 приравняем к 5 ? или хотя бы к 3,5....а то никак пол дерева не садяться под окно моего дома....
------

по поводу копирования данных...кхм...опять загогулина на ровном месте...нахрена копировать ? мона хранить обьекты и в одном экземпляре (лучше у Джэфри Элджера гляньте)... понимаете, я не привередничаю...просто Вы такие весчи рассказываете, что понимаешь или проспал лет 30 как минимум...либо консерватория не от той скрипки...

создаёться впечатление, что нехватка алгоритмов...стиля если хотите...простоты и эффективности...а сделать мона усё... я не против, лично - только ЗА (С)....

удачи Вам
(круглый)