LSV
* Сортировка по любому столбцу(группе столбцов) в гриде
...

кхм...
енто вообщето чиссо серверная задача...

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

Александр ГoлдунНе надо так категорично. В разных ситуациях применимы разные подходы.
Иногда эффективнее поручить серверу первичный отбор, а дальнейшие
манипуляции производить на клиенте. Далеко не самые мощные по нынешним
меркам клиентские рабочие станции прекрасно справляются с сортировкой
нескольких тысяч записей, не напрягая при этом сервер и не загружая
каналы связи.

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

почему так - долго обьяснять, да и думаю Вы и так всё понимаете. Для начала достаточно представить гигабитные массивы инфы и ответить себе на вопрос - а нафига качать и делать аля-дубль-СУБД локально ? Тем более достоверность
данной инфы, в многопользовательском доступе, теряеться с каждой секундой.

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

нет, конечно же мона запустить поток...начать вечную подкачку не понятно чаво и зачем... по выводимой инфе дозакачивать данные....потом с удивлением обнаружить, что из накаченного массива за 2 часа, пропали все 7 миллионов записей :)...что уж поделать - сеть. зато потестили операционку, и свопинг памяти - то же не в корзину занятие...


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

OTigerПросто для того, чтобы отсортировать уже полученную выборку, терзать сервер-ну просто верх расточительства, не сказать еще хужее.:)

Вы готовы получить гигабиты инфы на станцию ? :) Вы батенька крут... аназначно... Или Вы не хотите предоставлять пользователю последнии 20 записей из пару сотен миллионов ? это уже надувательство...

как там в анегдоте...Вы либо туды - либо сюды...

примеры, когда пользователю потребуеться одна-две-три записи - давайте не бум рассматривать. Или оговорим - тут возможна оптимизация...


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

OTiger
1.Какие гигабиты, какое надувательство? Зачем пользователю вываливать все записи существующие в БД? Я не буду тут распинаться на тему того что есть определенные объемы, которые человек способен переварить за раз, грузить больше - ГЛУПОСТЬ. Вы просто объясните зачем пользователю даются возможности поиска и фильтрации? Чтобы он это выбросил и тупо бегал по списку в поисках нужной ему записи?


Вы уважаемый сами се противоречите. Уже прозвучала мысль - либо туды...Либо сюды... То Вы за раз проглатываете все данные для обработки на клиенте. То Вы не собираетесь гнать гигабиты... Вы уж определитесь батенька... Либо Вы показываете на клиенте от балды ? Что не попадя ? Или всё таки грузите инфу, со всякими пользовательскими прижимами, подсветкой если бла-бла-бла формулой, динамической сортировкой, динамическими филдами из той же базы - менющиеся от одного до штук эннн ?.

OTiger
2. А мы и не будем рассматривать примеры с тремя записями.
Сколько СРАЗУ нужно Вашему пользователю записей, чтобы он мог комфортно работать? Тысячу, две, десять.
Вот только что через интернет подключился из дома к MSSQL БД своего клиента. Серверок купленный за 3тыс(ничего особенного). Связь посредством ODBC.
Прога грузит порядка 20000(20 тыс.) записей(товарный справочник) менее чем за 5 сек. Справочник контрагентов ~2000записей загружется вообще мгновенно. Это точечный запрос к серваку, при этом ты не даешь ему лишней загрузки в плане сортировок, подсчитывания общих сумм выборки, это все уже на клиенте можно сделать, да и удобнее, учитывая некоторый ограничения и неудобности SQL. Представляешь как это отрабатывается в локальной сети? Обычный GUI интерфейс. Зато уже загруженные данные я сортирую в любых комбинациях, при этом сервер не трогаю вообще. И по списку этому можно бегать от первой записи до последней-сервер не мучается.
Для учетных систем этого с головой. Никому не нужно чтобы эти записи постоянно изменялись. Когда ты делаешь любой отчет, ты выдаешь данные на определенное время и тебе уже пофигу что через 2 сек. картинка изменится.


я ПОЛНОСТЬЮ согласен с ПРАВИЛЬНЫМ взглядом на весчи по поводу обработки получаемых данных. Если человек - то не очень много, это и понятно. Если отчёт - то так же. Но простите - это ВЫ ПРЕДЛАГАЕТЕ ГНАТЬ ВСЁ НА КЛИЕНТА !!!

По поводу изменения картинки - знаете Вы глубоко ошибаетесь. Очень часто нужно в режиме ОН ЛАЙН видеть динамические изменения. Или скажем по другому - сколько часов хранения выбранной информации, Вы считаете эту информацию ликвидной ? Час, неделя, месяц ? Я сильно не завидую тем пользователям в работу которых введена временная составляющая влияющая на результат работы...

OTiger
3. Основная проблема всех учетных систем, включая самые "крутые" - низкая производительность, а почему? да все просто. Потому что пишутся как Вы предлагаете. При этом списки выводятся как правило постранично и когда пользователь начинает стрелками скакать по списку - сервер мученически попикивает и сетка загибается. Или еще того хужее используют в запросах курсоры SQL сервера и последний начинает тихо помирать.
И пошло поехало, выкатывают клиенту все новые требования к железу- Серваки за 20 тыс, переход с MSSQL на Oracle(почему то везде считают что MSSQL не тянет больше 50 пользователей-дурь полная) и прочая лабудень. А клиент считает что так и надо-а куда он денется, он уже подсел на иглу.


Низкая проивзодительность это менее секунды ? На нескольких десятках таблиц, с несколько киллобайтными диннамическими запросами, динамически добавляемыми пользователем полями и любой сортировки (и правил сортировки кстати) по любому полю либо комбинации полей ? Хочу, Хочу взглянуть на такую систему например на MSSQL.

То, что я предлагаю - это жизненная логика, обкатанная не на одном продукте между прочим. И именно оптимизация обьёма передаваемых данных -лежит в углу данной логики. Это передача на клиента именно НЕОБХОДИМЫХ данных со всеми бантиками описанными выше. Какие курсоры ? гы... какие писки ? По поводу оракла - Вы знаете именно когда была решена задача быстрого сканирования баззы БЕЗ ИНДЕКСА, но с учётом сортировки юзверя - вот тоды я зауважал оракл. Да, в тупую начириканные сиквол запросы будут тормозить как китайцы. Да, дилетанты за пару месяцев такое не напишут. Да, это трудозатраты. Но то, что клиентами данной контент системы выступали хорошо известные зарубежные марки - говорит само за себя.

OTiger
P.S. Я Вам так скажу, требуется свой подход к разному типу задач. Нельзя бросаться в крайности-всю обработку выносить на сервер или наоборот на клиента. Должна быть золотая середина для Вашей конкретной задачи. Проблемы учетных систем я как мог описал Выше. Может чересчур эмоционально :) устал чтото да и замерз седня слегонца.
Всем удачи.

Если у нас страна советов :) (шутка) То с Вашим постулатом о крайностях - ПОЛНОСТЬЮ согласен. И в каждой конкретной задачи нуна подходить с умом - БЕЗ обсуждения верно. Посему и выделил только конкретную задачу и подчеркнул об элементе оптимизации.

с уважением
(круглый)
ЗЫ
Если нам что то НЕ известно, то это НЕ значит - что этого НЕ существует (С)

OTigerЯ нигде не писал что проглатываю все записи, я говорил как раз о разумных ограничениях, и ограничении не в 2-3 записи, а вполне нормальной выборке данных.

критерий "разумные ограничения" - это в чём меряется ? и "нормальная выборка" - ту да же...??

OTigerВсе не надо, только то что закзал клиент.
Вы предлагаете ограничить клиента ? Или предпалагаете что НЕ найдётся такой клиент который скажет - ХАЧУ ВСЁ !!! Ну ХОЧЕТ ОН ! ииии что делать в таком случае ? говорить дескать это не "нормальная выборка" ? или предлагать "разумные ограничения" ? Типа давайте щаз выдам 100 тысяч, а через пол часа ышо 200 ?

OTigerПричем тут час, месяц? Клиент сам решает когда он хочет обновить данные.
И если он изучает статическую информацию, пытаться ему втюхать свежую-зачем? Тут ключевое слово, когда это нужно делать, а когда нет. Для обычных учетных торговых систем это нужно? зачем? в каких случаях?

поиск по подстроке, с выдачей текущей инфы по товару (к примеру)...понятное дело - мона представить всё в тумане - дескать круто вводите сначало то, потом сё...не бум КАК можно реализовать... Скажем - ХОЧЕТЬСЯ такой функционал и точка...

OTigerВот тут я чтото не понял. Менее секунды как раз нормальная
производительность. Только не видел я таковой у существующих "крутых" ERP-системах.

Про крутых - ничего не скажу. Я вообще, если заметили не заострял внимания на тонком-толстом клиенте. Потому, что подход к накачке станции данными - в первую очередь зависит от оптимизации трафика данных,а не от средств реализации клиента.

OTigerИх есть у меня:) И именно на MS SQL.
Только вот никак не врублюсь, зачем пользователю самому заводить поля в БД? Если по уму, это делается немного по другому...

Во-Во вот это мне нравится в спецах... Именно не решать задачи а пытаться завуалировать минусы того или ионого решения. В принцепе это не плохо. Но простите, не до такой же степени ! Задача очень банальна - без изменения системы иметь возможность описывать, вводить, удалять, изменять такие весчи как: имена таблиц связей, поля связей, поля показа, условия показа, способ показа, формулы показа, прижим и т.д. и т.д. и т.д...

[quot OTiger].....внедрение продукта как правило политический вопрос..../quot]

сюды не полезем... не бум про политику...

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