GaraZСам я только недавно начал изучать java
у меня сложилось впечатление, что Hibernate уместно использовать тогда когда нужно получить независимость от БД.
и когда разбиратся с тонкостями конкретной БД нет времени или желания
особо я преимуществ не вижу пока. хотя может пока просто не вник ))

Не правильно. Изменение RDBMS в крупной системе это на столько не тривиальная задача, что одним только Hibernate она не решается. Возможно частично. Но эта задача единоразовая и преплетать для неё такой фреймверк смысла нет.

Hibernate даёт возможность существенно экономить время разработки уровня работы с БД, когда у вас данные представляют из себя сложный граф. Т.е. между записями очень много ассоциаций. И вам часто приходится с этими ассоциациями работать.

Например вам нужно делать большую выборку из десятка таблиц. Hibernate позволяет очень простыми средствами менять структуру запроса на JOIN-ы либо подзапросы. И даже позволяет это делать динамически.
Разработка такой же задачи на pure SQL может занимать несколько дней. Приходится таскать несколько SQL запросов для одних и тех же таблиц в зависимости от того где они нужны. Решить N+1 через JOIN - перепистаь запрос почти с нуля. Оптимизировать JOIN через 2-3 отдельных запроса - переписать запрос почти с нуля. С Hibernate тоже самое делается в течении часа-двух.

maytonBlazkowiczС Hibernate тоже самое делается в течении часа-двух.
Звучит, как рождественская сказка, брадт. Ну дай бох.
Та ладно... Fetch Mode указал, перезапустил проект и протестил. Всё.
Я же не говорю что Хибера всё остальное работает без косяков. Но конкретно в этом вопросе экономия на фоне рукописных SQL радикальная.

HOME_XНасколько производительно работает данная библиотека ?

Достаточной для многих решений. А производительность единственный критерий качества ПО? Намного важнее чтобы оно горизонтально масштабировалось и просто поддерживалось.

HOME_XТ.е. используються ли ВСЕ возможности базы ?

Нет, конечно.

HOME_XА как насчет изменений версий это диалекта, скажем перешли с Oracle 10 на Oracle 11

Оракловый диалект, только для 8ки свой. Для остальных версий, общий.

HOME_XИли иной пример в Oracle 9-10-11 - есть предложение UPDATE - "тяжело" работает.
есть предложение MERGE (вроде для других целей),
но призводительнсть в разы больше, имеет ряд удобный доп. возможностей.
Соответственно делаю "насильственный" запрос MERGE.

Переписывается узкое место на SQL.

HOME_XОтносительно трафика сети и количества обращений к серверу ?

Что с ними?

HOME_XА другие механизмы базы (тригера, храним. процедуры, типа, job) HIBERNATE понимает ?

Частично.

Ещё важное достоинство в Hibernate это Level 2 Cache. К plain SQL такое прикрутить с нуля не просто.
И не надо рассказывать про то что RDBMS сама всё закеширует, на уровне Java кеши не нужны.

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
Дальше можно не читать.

LecterЯ не принимал участие в этом проекте, посему точно не смогу ответить что именно их не устроило.
Ну, дык, разговор ни о чем выходит. Я вам буду говорить что хибер можно использовать в не до конца нормализованых базах.
И я использовал. А вы будете отвечать, что мол нельзя, но не знаете почему.

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

По делу что-то есть сказать? Т.е. если у нас поверх тупого хранилища навернуть ещё и кучу логики в БД, то БД от этого будет проще мастштабироваться? Или с чем кокретно не согласен?