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

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

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