HOME_XПример - описал функцию с взаимодействием обьектов выложил на сервер.
Один раз обратился - передал параметры - получил результат.
Т.е. теряю гибкость и оператвиность в разработке ?
Слова знакомые, но я в упор не понимаю в чем суть вопроса? Какая гибкость? Какие функции?

HOME_XВ Hibernate - это описание отдельных классов. сколько обращений будет при выполнении
запроса

Это о чем вообще?

HOME_XТ.е. сколько получться классов -сколько будет и обращений к серверу БД ?
Верно понимаю ?

Это бред какой-то. Классы отдельно, "обращения к серверу БД" отдельно. Какая между ними связь вообще?
О каких вообще "обращениях" речь? SQL запросы? DDL запросы? SELECT выборки?

HOME_XОбращанию внимание что описать архитектуру базы сразу вряд-ли возможно.

Задача описания и ведения версий структуры БД решается отдельными инструментами. Например liquibase.

MasterZivНадо, надо.
К тому же весь этот кэш множится на 1/N, где N -- кол-во приложений (систем), работающих с БД.
А кэш БД -- он для всех.
Да я-то знаю. Просто здесь есть любители заявить что RDBMS всё прокеширует - другого не надо.

GaraZну не знаю я бы вынес сложный запрос в функцию

Это можно только если у вас запрос живет совершенно отдельно от структуры. Но зачастую получается и так, что меняя запрос вам придется менять и структуру. Так как это может группа запросов, например.

GaraZне совсем понял что это за запрос такой "N+1 через JOIN"
Это сложно объяснить на одной ассоциации. Проблема становиться явной, когда их несколько.
Есть Teacher, у него много Students. У Students ещё несколько ассоциаций. ТЗ у вас динамичное и в какой-то момент времени, вы обнаруживаете, что загружая одним запросом Teacher+Students, вы потом делаете N запросов чтобы догрузить детали Students.
Обратите внимание, что это вообще может нарисоваться на уровне бизнес-логике, а не на доступе к данным.
Чтобы решить проблему N+1 запроса вам нужно написать новый JOIN, с догрузкой новых деталей по всем Students of a Teacher.
В Hibernate - нового запроса не нужно. Указали что хотите в нужном месте читать с JOIN-ом - получили. Не меняя при этом структуры существующего запроса и логики.

ShSergeВот, ещё один "джедай".

Это слово оскорбительное, попрошу его ко мне не применять.

ShSergeВы, вообще, в курсе, что приложение на яве написаное во много раз дешевле, чем БД с процедурами, функциями и триггерами,

Как бе в курсе. Разработка на Javа дешевле разработки на других платформах. Для кого-то разве это ещё секрет?

ShSergeкоторые не только в яве будут работать, но и в делфях, сях, и т.д. и т.п.?
Ну, это аналогично заявленияв выше что Hibernate будет работать и на Oracle и на MySQL, поэтому он лучше. Никакого отношения к вопросу не имеет. Interop решается разными средствами. БД не единственное.

ShSergeОт явы только гуй требуется, которому цена - грош.

Какой нафиг гуй? Кто в здравом уме делает гуй на Java?

ShSergeБаза - совсем другое дело.

Ещё бы. Только к чему это?

ShSergeПоэтому, когда мне говорят про ормы, или про перенос с одной платформы (с одной БД на другую) на другую - я хватаюсь за пистолет.
Нервы ни к черту, или почему хватаешься?

ShSergeПС. А насчёт масштабируемости - нефиг трындеть! Масштабируемость или решается средствами сервера SQL, или вообще никак не решается.
ROFL

ShSergeВы мой пост прочитайте несколько внимательнее, или замолчите со своим рофлом.
Да, я тут всё время делаю то что велят.

ShSerge"джедай". Вы, вообще, в курсе ... цена - грош. ...я хватаюсь за пистолет.
... нефиг трындеть...
Это что Вас так задело? :)

GaraZно вы же всеравно должны описать какие доп атрибуты хотите получить
какая разница делать это на уровне запроса или на уровне Hibernate

"Доп атрибуты" прописаны в маппинге и ими управлять нет смысла.
А вот "доп ассоциации" они у каждого запроса разные и в то время когда на SQL требует отдельного запроса (набора запросов) на каждый сценарий, где одни и те же ассоциации нужны в разных комбинациях, в Hibernate достаточно использовать FetchMode чтобы указать какие ассоциации каким образом грузить.

GaraZНа счет масштабируемости по большему счету согласен с ShSerge
Если основную логику реализовать на Java, то масштабирование БД перестанет быть проблемой. Во-первых это тупое хранилище, которое проще масштабировать. Во-вторых нагрузка перемещается на Java и минимизируется на уровне БД, за счет чего надобность в масштабировании БД возникает гораздо позже.

GaraZесли будуте решать проблему масштабируемости только на уровне прикладного языка рано или поздно упретесь в базу (но это может быть не единственная проблема) чем нагруженее проект тем раньше
Тема в очередной раз показывает что программисты слишком много уделяют внимания производительности, забывая о других важных факторах успешного ПО.
Дело в том что пока вы пишете свой highload сервер, для юзеров, которых у вас нет, ваши конкуренты экономят человеко-месяцы разработки путём использования ORM и выходят на рынок раньше. И когда у них настанет проблема 10K, они уже заработают достаточно финансов для её решения и при этом наработают огромный knowledge base по узким местам системы, чтобы направить ресурсы именно на решение актуальных проблем.
А вы в только к этому моменту будете запускать свой highload сервер с чудесной масштабируемостью, которые нафиг никому не нужны. Ведь все юзеры уже у конкурента.

LecterНедавно коллегам пришлось отказаться от использования гибернета, слишком много ограничений для БД. Например, если данные не преведены в 3 форму то все пропало :)
Недавно это лет 10 назад? Hibernate 2 не умел работать с ненормализоваными структурами. Поэтому основной задачей Hibernate 3 было адоптация возможностей маппинга под любые legacy БД.
Возможно ваши коллеги больше используют табличные данные, чем сложные графы ассоциаций. Тогда выбор ORM, естественно был ошибкой. ORM это способ хранить объекты в RDB, а не спосособ представлять RDB в виде объектов.

GaraZя как человек несколько лет разрабатывающий на oracle
Дальше можно не читать.