alexx7262Vladimir Kozlov

1) Выполняем select * from table. В таблице имеем 200,000 записей.

Вопрос: Сколько записей поступило на клиент?
Ответ: ни одной до fetch'a


Ответ: В сегменты отката СУБД записалось 200 000 записей, в зависимости от СУБД клиент либо блокирует всех писателей (в некоторых СУБД), либо просто рискует нарваться на snupshot too old (как в ORACLE). Клиент терпеливо ждет завершения не нужного ему select (пусть пока на сервере).
При многих таких "клиентах", резко падает масштабируемость СУБД, подвисают важные отчеты ...
Ну нам то по-фигу, мы же умные - вот хотим 200000 записей и все тут. :)



2) делаем fetch
(executeQuery() да што угодно)

Вопрос: Сколько записей поступило на клиент?
Ответ: Столько, сколько уместится на экране (задано в параметрах и т.д.)


Ответ: зависит от того применяет ли клиент базы (не путайте со своим самописным кодом - это обычно стандратный класс для работы с СУБД) локальный буфер на жеском диске клиента.
По хорошему - на клиентский компьютер, в буферный файл (это если очень грубо) поступили ВСЕ 200 000 записей (ну, или см. ниже про lazy read), но ваше приложение (похоже и вас тоже) пока это "не колеблет". :)
Пользователь опять же ждет. В локальной сети вы этого почти и не замечаете, в WEB или ежели у вас реально нашруженное приложение - разговор с таким подходом уже закончен.


делаем PgDown, PgDown

Вопрос: Сколько записей поступило на клиент?
Ответ: 2 экрана

Ответ: см. выше + теперь еще в само приложение реально отобразилось (использует RAM) либо ОДИН экран, либо уже два (это зависит от механизма буферизации уже самого приложения).
Кстати, если в это момент вы захотите сделать столь любимую многими произвольную сортировку или добавить фильтр - интересно, вы понимаете, что придется проделать "за кулисами" такого требования при 200 000 записях? :)



1) Где здесь проскочила фраза про перелопачивание тысяч записей.

Увы, не пытайтесь изобрести чуда - в реальной базе, если это не read-only tables + lazy fetch или логика допускает чтение несогласованных записей (последнее IMHO верх уродства), то ваше приложение ОБЯЗАНО сожрать все, что оно запросило в максимально короткий срок. Иначе НЕ БЫВАЕТ.
Точнее, если вы такое наваяли, а ваш DBA немедленно не настучал вам по мозгам, то его надо уволить.



2) Где это реализовано в стандартной Java-модели. Да, ResultSet заточен для этого, но Grid-то не заточен.

Что реализовано?
ResultSet с перемещением в обоих направлениях - это и есть ваша "серебряная пуля" с буферизацией на диск - никакого отличия по принципу действия со всем, что вам знакомо.

Нужно действительное lazy read? Ну так читайте порциями, а гриду сразу скажите реальный count (если знаете приблизительное кол-во, то можно просто заведомо большее число).

И еще раз - GRID это отображение данных в удобной графической форме.
Это НЕ ОТЧЕТ!
Если клиент тянет в GRID даже 1000 записей, то вам надо срочно переделывать логику своей программы.



В GRIDe от SWING очень напрягает отсутствие наличия вариантов "для чайников" - ну всякие там фиксированные колонки и ряды, удобное форматирование числовых и строковых данных и т.п., т.е. налицо IMHO ослиные уши просто ленивых разработчиков.

И мне действительно пофигу, что я научился (более или менее) все это менять под свои интересы - спрашивается на кой ляд мне это надо, если меня стандартная GUI функциональность подобных гридов в других средах устраивала в 80% случаев?

А вот работа с данными тут реализована очень правильно и не надо нападать на MVC - очень грамотное решение.
Между прочим, по существу, в той же Delphi это приблизительно так и реализовано, только сокрыто от пользователя за семью замками, что отнюдь не способствует созданию хороших приложений.


Кстати, если не подходить к GRID как к "чудо огромно, озорно и лаяще" и выбирать действительно нужные данные, то всякие там мечты про сортировки, фильтры, группировки и другие извращения реализуются на порядок проще, чем в той же Delphi.


Несмотря на все вышесказанное, считаю, что SWING проработан недостаточно, отсутствует много функционала, который он обязан содержать, мало нормальных стандратных решений, и вообще, производит впечатление продукта, который ПОЧТИ довели, но помешало что-то другое.
Вот только раздражает, когда ему в вину ставят совсем уж к нему не относящееся, как в странном примере с 200 000 записей.
Или, того лучше, сильные свойства - например, мощнейшие возможности по самому изощренному форматированию объявляют отсутствующими просто потому, что сами ими пользоваться не умеют/ не хотят.

Vladimir Kozlov
А я вот никак понять не могу - даже при суперумном гриде (кстати, энтузиастам DevExpress рекомендую отселектить 200000 записей и включить в гриде фильтрацию) - неужели найдется такой пользователь который осилит все 200000 в гриде просмотреть? :)


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


А какие при этом финты ушами вытворяет ADODataset в связке с MSSQL - вообще не передать словами...

А какие, а то я не разбирался? Что-то особенного? :)



Но можно написать своё. Да, время теряется, которое можно было бы потратить на собственно логику программы. Но - время теряется один раз. Пишешь один раз - юзаешь везде.

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



У меня в наследнике TableModel живет более-менее похожий на дельфийский FieldsCollection :) Ну и соответственно всякие FindField, GetFieldByName, SetFieldByName. А теперь сюрприз - для вычисляемых полей есть флажок - вычислять один раз в пределах жизни модели или при каждом обращении. Причем это где-то там в кишках модели кэшируется и совершенно не озабочивает приложение.

Я бы все же вынес это, хотя бы частично, в шлюз таблицы данных.
А с вычисляемыми данными не совсем понял - зачем флажок?
null - считаем, что-то другое либо пересчитываем, либо нет, в зависимости от флажка?
Я правильно понял?
Если так, то для сложных вычислений IMHO правильное решение, а для простых вычислений, я бы лучше не кэшировал - память тоже штука дорогая.

alexx7262Carper

))))))))))))))))))

А вообще дискуссия даже на спор не тянет.



Извините, думаю, погорячился, вступив в дискуссию, можете продолжать в том же духе. :)

Ну разве что заступлюсь за TOAD - вы бы помониторили, что он реально делает на вашем примере из 200 000тыс. записей.