_usa__83_,

В тоже время таскать за раз из базы больше 50-100 записей вроде как и не очень разумно, а вот иметь доступ к записям если "основного" представления это не очень накладно вроде как и не очень плохо. Хотя ...
кто тебе сказал, что не разумно????
базы они для того и предназначены чтоб выдавать данные какие нужны, а не все.
можно по пальцам пересчитать когда юзеру нужно просматривать 1к записей, и это только если просто просмотреть....
максимум- 2 экрана, если вывод больше - не правильный фильтр для выбора. и фильр надо делать именно в запросе, а не на клиенте фильтровать из мильона записей.
для базы менее накладно выбрать n-раз из мильна записе 50 и их отправить клиенту, чем выбрать все и отправить.

mad_nazgul,
хорошее знание sql позволяет очень много реализовать именно на sql, что обеспечит и скорость и простоту кода.

Blazkowiczвадяmad_nazgul,
хорошее знание sql позволяет очень много реализовать именно на sql, что обеспечит и скорость и простоту кода.
Простоту кода? Когда у тебя по десятку JOIN-ов на запрос? Не смеши.
не надо утрировать, десяток джойнов это не много,
если для тебя это много, значит ты не очень хорошо разбираешся в базах. количество джойнов не является определением сложности.

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

авторУже сам забыл какую херню написал про "простоту кода"? ORM как раз позволяет избегать однотипных запросов с массой JOIN-ов. Когда у тебя в системе пачки жирных SQL ни о какой "простоте" речи быть не может
если для тебя написание хорошего запроса является сложностью - это твоя проблема.
однотипные запросы это не проблема и этого пугаться не стоит.
c помощью ORM невоможно построить наиболее быструю систему, ни одна прослойка не сможет заменить голову программмиста, владеющего нормальными знаниями sql, ни одна прослойка не сможет воспользоваться всеми возможностями каждой субд.
все эти прослойки используют лишь минимальную часть возможностей субд.
ни одна прослойка не сможет использовать (в применении к mysql) операторы case, concat, concat_ws, group_cocat и куча прочих.
по сути прослойка - это только джойны.
я для этих целей использую знания и специализированный инструмент, поэтому сделать запрос из любого количества таблиц и джойнов не проблема, помимо этого есть и подзапросы и функции и представления. которые позволяют многое,
это то, что ориентированно именно на работу с большим объёмом данных.
это то что позволяет выдать в код java наиболее быстрым образом наиболее подготовленные для дальнейшей обработки и отображения данные. по факту уже готовые для отображения.
и поверь , что алгоритмы и методы баз работают намного быстее , чем код на java.
авторКто с этим спорит? Я точно так же знаю десятки примеров, когда построение системы начинают с GUI. Выходит Delphi - говно.
это не значит, что эти примеры - правильное построение систем.