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


а вы не правоцируйте.


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

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

Позволю себе внести маленькое дополнение в дискуссию. Недавно я все писал на JDBC руками и так, как работаю на Oracle, я понимаю DimW. К сожалению ORM системы типа Hibernate просто не дают использовать мощь Oracle по полной схеме. Однако в пылу полемики он несколько перебрал.

Здесь много говорилось о запросах, и почти исключительно о запросах, когда приводились примеры. К сожалению боле сложную часть работы с базой представляют собой управление транзакциями в приложении (в большинстве приложений). А вот здесь ORM системы не просто укоряют работу разработчика, а делают ее существенно эффективнее.

Бывают "крутые" отчеты, выполняющиеся часами. Это особая "песня" и никто не мешает выполнять их запросы вообще за пределами ORM системы с помощью JDBC и оптимизировать до потери пульса. Оптимизировать же множество коротких запросов в транзакционной системе смысла нет.

Можно вообще пойти на компромисс. Oracle10g позволяет выявлять особо нагружающие систему запросы. Оптимизируйте их с помощью Native SQL но в рамках ORM системы.


Это сообщение отредактировал(а) mbasil - 26.9.2008, 10:36

Вообще говоря имеется две психологии разработчиков:

1. Идти от базы, считая приложение (отчасти) вторичным.
2. Идти от приложения, считая базу свалкой таблиц.

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

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

это короткий запрос?


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

mbasil, ну так что забиваем на это и пусть фулскан по таблице делает свое грязное дело?

DimW, передергиваете. Несомненно анализировать запросы и тюнить базу необходимо. С этим никто не спорит.

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

Ну да, я несколько утрировал. Сознаюсь и каюсь.
Однако ваше, DimW упорство в отстаивании крайней позиции достойно сожаления.
Еще раз подчеркиваю, я очень бы хотел вернуться в те прекрасные времена, когда система писалась неспешно, вручную, изменялась неторопливо, а Программист был магом, а не работником конвейера.  Когда я начинал писать программы, а было это в восьмидесятых годах разработка программ была искусством. Сегодня это индустриальный, зачастую автоматизированный процесс. Это прискорбно, но факт и от ORM систем не убежать. Дальше будет только хуже.

Это сообщение отредактировал(а) mbasil - 26.9.2008, 13:42

Грань очень простая. Потребность бизнеса и трудозатраты.  Если оптимиизация запроса с 0.05с до 0.0025с требует человеконедели, то пошла бы она эта оптимизация. Другое дело, если тот же запрос является критичным участком, тогда и больше не жалко.

и на том спсасибо 


Честно говоря, больше принадлежу ко второй - но это не моя идеология. Просто так получилось. Но пихать ВСЮ бизнес-логику в СУБД я тоже не хочу. Мне более по душе средний вариант. Да и люблю я программировать "обычные" приложения (не СУБД).


Это очень интересно. Я никогда раньше не разрабатывал транзакционных приложений, однако уже вижу, что без транзакционных процессов в соц. сети не обойтись. Соответственно Ваше заявление меня заинтересовало. Как именно ORM framework упростит/ускорит этот момент и какой именно framework Вы рекомендуете в данном ключе, если у Вас есть в этом опыт? 

Можно сказать только начинаю. Выбор прост (поскольку, я полагаю, надо быть в мейнстриме) изучаю JPA, вследствие того, что это стандарт и Hibernate как наиболее часто используемый (хотябы даже из тех соображений, что JPA делалось по образу и подобию Hibernate и может использовать Hibernate в качестве поставщика постоянства).
Рекомендую замечательную книгу "Hibernate In Action".

Впрочем если вы сильно сориентированы на решения Oracle, можно в качестве поставщика постоянства использовать Toplink (однако последний является платным, а бесплатная версия сильно урезана).

В общем рекомендую JPA и Hibernate или native Hibernate.

Это сообщение отредактировал(а) mbasil - 26.9.2008, 17:04

mbasil, поясните пожалуйста связь между транзакциями и ORM, и о каком управлении идет речь.
или это два обсолютно не связанных друг с другом предложения(я про цитату)?


CaligoSpiritus, ни как, почитайте определение транзакции и сами поймете, mbasil скорее всего в терминах проявил неосторожность.


CaligoSpiritus, управление транзакциями СУБД обеспечивает самостоятельно, повлиять можно только на уровень изоляции настройкой на уровне СУБД. вы говорили что у вас есть опыт в оракл, поэтому любое ПО написаное вами использующее СУБД оракл без таковых процессов работать не может. поэтому можно сделать вывод что вы сами не понимаете о чем вы спрашиваете.

с этим я с тобой соглашусь..   



а с этим нет..   



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



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



Это сообщение отредактировал(а) polosatij - 26.9.2008, 17:45

polosatij, это замкнутый круг, сначало кучка засранцев что то пишет, потом нанимают спецов что бы все это дело задышало, потом отказываются от них из за стоимости, опять пишут засранцы и т.д.
бабло, бабло, бабло... :(

Здрасте.

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

А сервера приложений со своим ORM, фактически стандартизируют все это управление объектами, плюс регистрация пользователей и раздача прав.
Не понимаю как можно не видеть очевидные вещи.

у нас на фирме хотя и пишут серъёзный код (самолёты), но чего я, наверно, не понимаю.
мне говорят:

- это, ты доделаешь потом.. как-нибудь в третем релизе..
+ т.м. Вы хотите качественный софт или чтоб пнуть и всё зазыпалось к ... -фени?   
- мы хотим быстро и денег срубить и качественно (но очень быстро!).. (молчание обозначающее это)

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



ага.. программирование - это не искусство.. это тупая быстрая работа без энтузиазма для денег чужому дяде..