DremmmСогласен с тем что
>>Он пригоден только для простых вещей
Полгода и ним ебал??ь, пишем NMS, но наверно у нас предметная область не та, или разработчик БД "неправильный".

Кто понимается под "разработчик БД"? Тот кто схему в базе наваял, или тот кто пишет код для взаимодействия с db?

Dremmm
ИТОГО:
>>а) пользоваться кешем второго уровня.
только мешает, т.к. кэшировать selectы БРЕД


Кешируются не select'ы. Кешируются объекты предметной области.
Если есть основания полагать, что ветка дерева объектов остаётся неизменной в течении хотя бы десятка циклов request-responce, то имеет смысл подумать о кешировании.

Неужели ваша система - это просто набор javabeans один к одному положенных на строки таблиц, к тому же изменяющихся с огромной скоростью?!

Dremmm
>>б) писать критерии, которые позволяют вытащить из базы только те данные, что действительно нужны.
Писать критерии к 8-10 объектам, Hibernate вроде для облегчение разработки, SQL это делает проще


Sql - это решение "в лоб".
Написано "select" - значит пошёл в базу, и плевать, что тремя строчками выше был выполнен такой же точно селект.

Это приводит к подобному коду (transaction script согласно Фаулеру):
В таком коде даже функциональная декомпозиция с трудом выживает, т.к. хрен поймёшь какие обращение к dao (или jdbc) были/будут сделаны выше/ниже по стеку вызова методов и где начало/конец транзакции, а значит избежать дублирования запросов практически не реально, равно как и обеспечить бизнес транзакции.

Конечно, это можно обойти, но только через постоянные кодоревью и жесткие предписания "как делать не надо".

Hibernate же позволяет выполнять "физические" select'ы "перпендикулярно" к написанному коду.

Допустим у нас есть метод Х, которому нужно получить какой-то объект.

Если в текущей транзакции мы уже достали этот объект из базы, то вместо запроса к базе, будет выполнено обращение к кешу первого уровня.

В другом контексте, объект может быть будет получен из базы или кеша второго уровня.

Если в какой-то момент мы понимаем, что потребуется вытаскивать не один-два объекта, а много (и каждый в своём методе ака Х), то мы можем выполнить fetch нужных нам веток заранее, что позволит избежать лишних запросов.

Чтобы проделать аналогичные действия пользуясь простым jdbc, придётся расписывать sql для каждой транзакции от начала и до конца, либо писать свой orm. Это "не плохо", но порождает значительное количество кода, которое нужно поддерживать, что в конечном итоге только усложняет разработку.

Имхо, лучше иметь 7 человек, которые пишут ООП (!) код и не вникают глубоко в проблемы ОRM маппинга и одного человека, который хорошо понимает, что это такое и занимается профилированием хибернейт, чем 20 человек страгающих jdbc и считающих себя гуру в SQL и хинтах оптимизации запросов оракль.

Dremmm
>>д) там где действительно "тяжело" - можно написать несколько native sql или stored procedures
К этому и пришли, т.к. при разработки ПО все не просчитаеш, даже "чтение мыслей заказчика" не поможет, а stored procedures являются "более стабильным интерфейсов" между разработчиками.
В итоге Hibernate используется только как Connect к БД, Hibernate must die!

Такой hibernate, действительно, должен must die. Имел дело с такой жутью :)

А stored procedures - зло.
Т.к. это всегда
- привязка к диалекту конкретной бд
- процедурный код
- вынесение логики из приложения, а часто и её дублирование (т.к. наверняка будет "обычный" код, работающий с теми же ассоциациями)
- усложнение процесса внесения изменнений в, тестирования и деплоя приложения
- повышение требований к рядовому разработчику (знание языка процедур, особенностей конкретной бд, инструментов для неё и т.д. и т.п), либо усложнение орг.структуры.

И, главное, ООП в таком окружении идёт лесом. А я его люблю, вместе со статической типизацией на каждом углу :)

Dremmm
Если есть готовая БД и к ней нужно написать новый интерфейс, тогда Hibernate может и прокатит....
Согласен. С места в карьер переписывать существующее решение под hibernate может оказаться тяжело. Поэтому нужно сначала разобраться в том, что он из себя предсталяет, построить стратегический план рефакторинга и ещё раз подумать о трудозатратах :)

Смысла не использовать хибернейт в новых проектах не вижу. Разве только сразу брать ejb3.

Dremmm
>>туча строк повторяющегося кода с созданием Statement-ов
туча строк повторяющегося кода с созданием критерий.

При использовании хибернейт, если замапить все ассоциации по человечески, большинство sql превращаются в простые вызовы методов get, что существенно уменьшает потребность в создании критерий.
В конце концов, ни для кого не секрет как избавляться от дублирования :)


Timmm
б) легко решается надстройкой над ждбц. удобно, практично. ждбц в явном виде использовать вообще некошерно.

Вот как раз в той самой книжке, в самом её начале, рассказывается о процессе эволюции "надстроек над jdbc" в ORM инструменте и о хибернейт, как о качественном ORM, который экономит кучу часов разработчика на написание собственных поделок.

Ora-JuniorВот у нас работа так сделана:
когда увидели,что hibernare генерит откровенную херню при соединениями таблиц,то сделали так.
Сложные запросы стали прятать в представлениях - а Java-объекты уже мапятся на них. Т.е один фиг запросы ручками писали.Вот и вся хваленая инкапсуляция HIBERNATE.
на что он способен - это на простейший маппинг

А lazy ассоциации в маппингах и индексы в бд не пробовали делать ?

Timm NotGonnaGetUsА stored procedures - зло.
Есть задачи которые при решении через хибернейт будут проигрывать ХП разы в скорости. Естественно те которые предполагают доступ к большому количеству объектов.

Проекты, где > 50% sql предполагают доступ к большому количеству объектов - нонсенс (не смотря на то, что они могут существовать).

В остальных случаях hibernate, как МИНИМУМ экономит время на писание и последую поддержку "простого sql", что само по себе оправдывает его использование.

Про скорость... Могу констатировать факт, что join'ы 6 табличек, количество строк в которых доходит до 20.000.000 (oracle), вполне себе шустро выполняются, когда заданы ясные критерии в запросе.

В случае, если каждый запрос превращается в многоэтажный sql, имхо стоит подумать над тем, что за дурак рожал схему.

Dremmm
Кто-то из великих сказал:
1. "Если вы умеете писать ООП, это не значит что его нужно везде использовать"
2. "Человеку освоевшему молоток, все вещи кажутся гвоздем"

1.
Однако, в той области где применяется java в 90% случаев ООП не только можно, но и нужно использовать. Иначе язык просто не верно выбран и говорить о плезности/вредности "хибернейт" просто глупо.

Если в приложении есть бизнес логика, если эта логика не статична из-за "особых" условий, то адаптировать ОО приложение к изменениям в пожеланиях заказчика существенно проще, чем менять схему БД и переписывать процедуры.

У Мейера, есть замечательные слова о необходимости "бесшовной" разарботки ПО, когда переход от одного уровня абстракции к другому не приводит к смене используемой парадигмы: язык описания абстракций должен сохраняться.

2.
Не зависимо от того, что существуют области, где можно обойтись без ООП, не имеет абсолютно НИКАКОГО смысла, превращать уместное ООП решение в скопище процедурного кода.

Dremmm
>>- привязка к диалекту конкретной бд
Использование ПРЕИМУЩЕСТВ конкретной бд

НЕ НУЖНЫ эти преимущества при написании 90% кода. В оставшихся 10% сколько угодно - этого никто не запрещает, эта даже необходимо.

Просто бессмысленно из-за этих 10% отказываться от общего упрощения процесса разработки.

Dremmm
>>- процедурный код
думаем над словави "великих"

Подумали. Идёт в топку процедурный код.

Dremmm
>>- вынесение логики из приложения, а часто и её дублирование (т.к. наверняка будет "обычный" код, работающий с теми же ассоциациями)
логика на SQL работает в 100-10000 раз быстрее

А также пишется и поддреживается в 100-10000 раз медленее.

Месяц работы программиста стоит больше, чем покупка дополнительной машины в продакшин.

Аналогия между asm vs c и sql vs orm очень уместна. Подождём какое-то время и возникнет конфликт "c vs c++" и "orm vs объектные бд" :)

Из-за того, что имеются уникальные условия, где использование sql может быть оправдано (вместе с дублированием кода и прочими прелестями), не значит, что в остальных случаях нужно также точно злоупотреблять вышеобозначенными антипаттернами.

Dremmm
>>- усложнение процесса внесения изменнений в, тестирования и деплоя приложения
а чем деплой усложняется?

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

Dremmm
>>- повышение требований к рядовому разработчику (знание языка процедур, особенностей конкретной бд, инструментов для неё и т.д. и т.п), либо усложнение орг.структуры.

Каждый должеyн заниматся СВОИМ делом, один человек и не должен знать все методы каждой формы GUI, и все таблицы, отношения и индексы в БД.
Одни пишут БД, и вьюхи, другие рисуют GUI к ним.

А третьи пишут бизнес логику, четвёртые пытаюстся заставить первых трёх понимать нужды друг друга? :)

Это и называется усложнение орг.структуры.

Как в неткракере, н-р, когда пожелание от тех кто пишет GUI, до тех кто добавляет метод из двух строчек в ядро, может идти полгода.

Где-то такой подход оправдан, где-то нет. Оправдан главным образом там, где больше важна ГАРАНТИЯ результата, чем СКОРОСТЬ его получения. Т.е. очень крупные проекты, в очень крупных софтварных компаниях, когда риски связанные разработкой значительны.

И опять таки, это не повод выкидывать во всех остальных случаях orm инструменты и струячить код напрямую в бд.

Ora-Junior NotGonnaGetUs
...
В случае, если каждый запрос превращается в многоэтажный sql, имхо стоит подумать над тем, что за дурак рожал схему.
....


Давайте еще будем ломать модели БД для того ,что HIBERNATE мог быстро работать:-)) Главное упростить разработку на HIBERNATE, остальное можно усложнить:-)))))

Друх, идиотская схема в бд - идиотская не зависимо от того, используется хибернейт или нет.

Могу привести пример.

В базе данных хранится набор "задачек". Задачка это описывается набором простых вопросов (мальтиплчойс, string/number field) и ответами на них.

Для это в базе были сделаны (примерно, точно уже не помню):
1. Табличка для Задачек ( Activitiy {ActivityId, Title, ChapterId}).
2. Табличка для списка вопросов ( ActivityParts {PartId, ActivityId, ...}).
3. Табличка для самих вопросов ( ActivityCell {CellId, PartId, ...})
4. Табличка c ответами ( ActivityAnswer {AnswerId, CellId, ...})
5. + Почти аналогичная структура для хранения ответов на задачки.

Безусловно, в такой БД каждое обращение к задачке вызывает многоэтажные sql. Как следствие, для УСКОРЕНИЯ работы написали views и stored procedures, которые через эти view пытаются выбрать необходимую информацию.

Очень близкое вашим идеям решение.

А имеем на практике?
- Пара sql запросов игнорируя views' + обработчик на стороне java приводит к коду работают раза в 3-4 раза быстрее той же процедуры.
- 4 таблички могут быть успешно заменены одной, где каждая задачка описывается простым xml-файлом, что даёт просто бесконечную по сравнению со старым решением гибкость в создании разнообразных типов задач + исчезают все многоэтажные sql конструкции.

Т.е. вместо изучения "тонкостей и преемуществ" конкретной бд, время можно потратить на реализацию требований заказчика.

Vadya NotGonnaGetUs...
Т.е. вместо изучения "тонкостей и преемуществ" конкретной бд, время можно потратить на реализацию требований заказчика.
Заказчик наверное будет в восторге от качественно написаной системы,чем от "быстрой" разработки,где каждый клик "подвисывает" базу

И к чему вы это?

Хочется поговорить о счастье заказчика?
Так его в восторг приведёт не качественная система, а быстро написанная и удовлетворяющая всем его требованиям (включая производительность)...