GKS_SamaraПри этом писать тупо селекты
а придется

GKS_SamaraЯ так понимаю, MyBatis?

хрен там. майбатис ничего за тебя не делает, это ни что иное как декларативный способ написать спринговый RowMapper и засунуть sql в ресурсы (ну плюс пару плюшек в виде динамического sql кода). запросы и маппинги придется либо писать руками либо юзать какой-то генератор на основе метаданных (в ibatis был какой-то, не знаю перекочевал ли он в mybatis) - причем в те времена он был довольно примитивным, т.е. мог сгенерить только CRUD, никаких тебе джойнов 5 таблиц.
имхо самое скучное в mybatis это когда тебе нужны разные наборы полей одного объекта на разные случаи (ну например один раз только id и имя, другой раз все плюс 2 вложенных объекта, все плюс 3 вложенных объекта со своими вложенными объектами и т.д.) - придется мастырить кучу маппингов из комбинаций n x m полей, а также селектов с джоинами. в этом плане мне hql гораздо больше импонирует. лично я бы начал с хибером (как самой быстрой реализацией в плане говнокодинга), отгородившись от него интерфейсами и, если не устроит, подумал о чем-то ином - либо написал Ibatis/JDBC реализации там где надеешься получить выигрыш в скорости.

Petro123chpashaон был довольно примитивным, т.е. мог сгенерить только CRUD, никаких тебе джойнов 5 таблиц.
из CRUD ему нужна только буква "S"
да, но я так подозреваю нужны громоздкие селекты, а не select * from t


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

IDVsbruckОчень рекомендую изучить HQL, чтобы не смотреть на org.hibernate.Criteria.имхо у каждого свои цели. criteria больше для динамических запросов, где иначе понадобилась бы жестокая конкатенация hql-строк

Petro123не люблю, когда нет альтернативы (Хибер \ Спинг).
А тут. задача, как раз для них - Простых проектов.
как раз задача не известна.

Petro123Можно даже вьюху сделать в БД
VIEW ПокажиЗадолжников
все это годится, когда три таблицы и две сущности. потому что на деле нам как правило понадобятся
ПокажиЗадолжниковСАдресами, ПокажиЗадолжниковСРодственниками, ПокажиЗадолжников, ПокажиЗадолжниковУдаленных,
ПокажиЗадолжниковИзМосквы

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

Petro123chpasha,
Ты ни разу не делал вьюху?
Петро, из моих слов можно как раз догадаться, что я делал вьюху и не раз. к сожалению ты не прочитал то, что я написал, или прочитал, но не понял.

Petro123Вьюхи убирают join вот и все.
вьюхи сами себя не пишут, и для каждого нового набора данных нам нужна другая вьюха с другими комбинациями таблиц (если мы не хотим написать одну супер вьюху с 10 джоинами и 300 полями на все случаи жизни).
а в хибере я написал "from Client p join fetch p.Address" получил вьюху клиентов с адресами. написал join fetch p.Firma - получил вьюху с фирмой и т.д.

Йуный джавистЪВьюхи - это код, он должен жить в SVN
ты у нас вроде нелюбитель лишний работы, ну вот и расскажи мне зачем всем проектам на земле хранить в vcs полный дамп базы?

Йуный джавистЪСледовательно, вьюхи должны быть уже отсортированы в порядке зависимостей.
что конечно отменяет необходимость либо добавлять новое поле во все из них, либо писать * в каждой зависимой.

Йуный джавистЪя считаю что вложенности 5 должно быть достаточно для любого приложения.
на этом месте я подумал, процитировать ли мне Гейтса с его 640кб или съязвить по поводу того, что 5-уровневая вложенность это конечно же фигня.

з.ы. кстати Петро, вот человек хотя бы понял о чем я.

Petro123chpasha,
Смишно противопоставлять HQL / SQL вьюхам.
расскажи в чем смех? sql вьюха это материализованный в бд запрос. hql это материализованный в коде запрос. когда вьюхи используют для защиты таблиц от прямого доступа - это другая история. здесь речь шла о "борьбе" с джоинами.

Petro123И не собираюсь спорить)).
та если бы ты читал, что пишут и отвечал по теме...

Petro123chpasha,
Вьюшка призвана упрощать и ускорять Сложный sql Запрос.
как и HQL (ну овлекаясь от конкретных реализаций вьюх и связанных с этом плюшек, которые есть не у всех).

Petro123Чё ты на них ополчился? )))
ты опять не пытаешься отвечать на то что пишу я, а говоришь о чем-то своем. я не ополчился на вьюхи. я их достаточно много использую и пишу о том, какие с этим связаны недостатки.

Petro123chpasha,
Ну и здорово. Недостатки есть у sql hql view.
Предложи альтернативу Хиберу в простом проекте.
я бы сформулировал так - пока ты точно не знаешь, почему именно здесь нельзя хибер юзать, лучше его и юзать (в смысле удобней). сдается мне что проблемы с его использованием могут возникнуть как раз либо в больших проектах, либо очень специфических. например места, где лично мне быстрее накалякать на jdbc/jdbcTemplate, проектом назвать сложно.