Уже два года программирую на Java, но никаких "больших" проектов еще не делал. Решил, что уже пора. И вот, с сотрудником решили написать небольшую социальную сеть (по крайней мере, для начала - небольшую  ).
Технологии намереваемся использовать следующие:
Spring Framework, Spring MVC, Hibernate для работы с БД, Velocity для  темплейтинга.
Однако, на счёт остальных компонентов пока сомневаемся.
Для пользовательского (web-browser) решено использовать AJAX, но какой движок выбрать? В "Pro Spring" советуют DWR, а какие ещё есть варианты, какие преимущества?
У сети будет тяжёлая фото-составляющая. Отсюда вопрос, как лучше хранить изображения - в файловой системе или в БД? (БД планируем использовать Oracle).

Ну все это хорошо и очень даже удобно использовать. Но вот DWR  я бы не рекомендовал.  Лучше просто использовать какую-нибудь javascript библиотеку (ExtJs, JQuery), где очень удобно делать AJAX-запросы. На мой взгляд это надежнее.

На первый взгляд понравилась jQuery, но на сколько удобно её можно интегрировать со Spring MVC? Ведь там будут не просто AJAX запросы какого-то контента, вроде кусочка html или картинки, это будет запрос к слою сервисов. (Не уверен, на сколько это умный вопрос - с разработкой на JS ранее не сталкивался). В случае DWR всё понятно - вызываем функцию (на подобие RPC) она отрабатывает и возвращает результат, DWR занимается маршаллизацией этого действа.

а я бы не рекомендовал Hibernate. лучше юзать обычные JDBC запросы. Потому как при использовании Hibernate ваша соц.сеть упадёт при большом кол-ве online пользователей. Hibernate чаще всего применяют для админских целей (страниц).

Не надо путать DWR и тот же ExtJS - это разные вещи.
DWR служит для удобного интерфейса JavaScript обхектов на Java - т.е. на серверную часть. А ExtJS - это чистый JavaScript. Так что они прекрасно совмещаются. У нас в проекте как раз такая связка работает. Да еще и JSF подмешана. На серверной стороне Spring, Hibernate.
И вполне пристойно все получается.

не думаю что она куда то упадет именно из-за хибернейта, не вижу причин... 

а насчет самому писать запросы - так это много времени уйдет ;)

а так посоветовал бы Flex как бэкэнд (ну или что то более экзотическое из РИА)

а еще посоветовал бы юзать платформу facebook если хочется соц сеть ;) идея как для обучения в принципе сойдет но имхо можно придумать что то более интересное 

Это сообщение отредактировал(а) seth - 22.9.2008, 15:18

[QUOTE=seth,22.9.2008,  15:16]
Писать самому долго??? О_о Не сказал бы. Всё зависит от вашего уровня знаний. 


Лан, это уже offtopic идёт...

Это сообщение отредактировал(а) dEEp - 22.9.2008, 15:22

Были прецеденты? Каковы причины? 
Интересно очень, ибо сами в проекте расчитанном на большое количество пользователей используем JPA на базе Hibernate. Было бы круто узнать про грабли чтоб потом не напороться. 

[QUOTE=dEEp,22.9.2008,  15:22]
тут дело не в уровне знаний а в технологии - SQL хороший язык только не для всего ;)
а для работы с объектами (да еще и имеющих сложные иерархии наследования) и связями между ними уж больно долго будут писатся все необходимые запросы из-за их большого колличества и сложности...
когда на хибернейте вобщемто генерация кода и мэппингов решит много проблем ;)

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

ссылка для автора топика, читать "Подход с использованием принципа черного ящика": http://www.citforum.ru/database/oracle/kyte/
CaligoSpiritus, поскольку ты выбрал именно оракл, то либо ты следуешь советам Т. Кайта, либо просто моменяй СУБД.


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

для оракла существует аналог хибернейт , звётся он TOPLink.

в TOPLink есть возможность менять запрос, или он так же генерируется как в хибернейт?

да, 
но
DimW, в хибернейт тоже есть возможность менять запрос 

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

А социальная сеть будет открытая, или закрытая (только для зарегистрированных пользователей)?

Есть необходимость индексации проекта поисковиками?
Если есть - читаем про СЕО и ограничиваем применение ajax только там, где это не вредит СЕО.

 А JSF вообще лучше обходить стороной, мало  того что с СЕО несовместимо, так пользователи материться будут - ни ссылку другу не пошлешь, ни в избранное сохранишь....

а можно подробнее, почему?
конкретные примеры, если возможно.

не верю. аргументы в студию!

Asal, 
dEEp, 

Свое мнение и доводы против JSF я высказал в этой теме:
http://forum.vingrad.ru/forum/topic-213156...tml#st_0_view_0

ok.

О каких конкретно запросах идет речь? На получение/изменение данных? Так их всегда самому можно написать в Hibernate. Если это DDL запросы на создание таблиц БД, то, впринципе, проектировать от БД к объектам никто не запрещает. 

P.S.: Теме когда лучше использовать ORM фреймворки, а когда голый SQL посвящена одна из глав книги Мартина Фаулера "Архитектура корпоративных программных приложений". Там достаточно подробно описаны плюсы и минусы технологий в зависимости от сложности проекта.

только на получение данных.
изменения данных я описываю хранимыми процедурами на уровне БД.
про DDL и речи быть не может, это этап проектирования, а не работы приложения.


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

и снова вопрос: имеет ли смысл использовать ORM фреймворки в моем случае?
мне просто хочется понять какое приемущество я получу используя их, а не голый jdbc.

так тогда не понятно какой ваш случай? у ТС это небольшая соц. сеть а у вас то что? 

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

хотя мне кажется опять же что проще сделать на хибернейте и купить мощнее сервер - дешевле будет 

в минусах от jdbc - долгая разработка + зависимость от БД

ЗЫ а так действительно лучше Фаулера почитать )

поверьте, нет систем которые не зависят от СУБД, невозможно без переработки кода просто взять и перенести ПО на другое СУБД.


и что Фаулер советует поступать именно так?!

Но для этого не надо километры кода менять.
Не понравилась MySQL пожалуйста, поменяй одну строчку в persistence.xml и используй другую БД.
Не хочешь Hibernate + MySQL, а хочешь Oracl + TopLink, поменяй 5 строчек.
Но это если работать с JPA.

P.S. ИМХО

я не спорю что после изменения этой строки ваше приложение сможет работать с другой БД, но вряд ли бизнес процессы которые изначально были определены будут работать так же.
простой пример:
есть таблица в БД с названием test
она содержит след. поля и значения:
поле: name
значения: 1, 2, 3, null

некое ПО было написано под БД MS SQL. кончепцией этого ПО является - "не показывать данные с пустыми значениями".
програмист выполнил задачу написав такой запрос:


после миграции системы на оракл главная концепция ПО перестала работать т.к. данное условие "name <> null" в оракл возвращает false- следовательно пользователь перестал вобще получать данные.
и только переписав запрос таким образом:

мы получим необходимый результат.



Asal, это верно! действительно ПО будет работать с новой БД, но как?!
так что любой кто утверждает что он написал ПО которое может работать под все БД(без переписывания кода), говорит это только по тому что он не пробывал его мигрировать на другую БД.

Это сообщение отредактировал(а) DimW - 24.9.2008, 11:08

социальная сеть это задача которую нужно решить, а не подход к разработки. 
так что не понятно?


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

так едрен-батом, кто нибудь ответит мне на мой поставленный вопрос - как в моем случае мне помогут ORM фреймворки?

Это сообщение отредактировал(а) DimW - 24.9.2008, 11:26

мне кажется только переносимостью спасают. 

я никогда не отказывался от jdbc и отказываться не собираюсь.

dEEp, мне тоже кажется что это один из весомых аргументов на который "ведутся", но хочеться услышать остальные доводы.

Это сообщение отредактировал(а) DimW - 24.9.2008, 14:46

А что у вас за случай? А то, кроме максимизации производительности взаимодействия с СУБД, других требований нет? С таким единственным критерием то конечно, - JDBC лучше.   

DimW, во-первых это было мое ИМХО.
во-вторых есть такая штука как

разве оно не за это отвечает ?

а я этого не утверждаю   

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



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



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

самостоятельно написать запрос можно не на диалекте , а на HQL - встроенный sql язык в  хибернэйт, который hibernate-core затем сам преобразует в указаный диалект.

Добавлено @ 15:27


а какая у вас СУБД не  оракл случаем?

Это сообщение отредактировал(а) v2v - 24.9.2008, 15:28

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

это я и имел ввиду, только забыл сказать   
например 

он самый.


еще раз говорю, ну не смогу я оценить произвадительность запроса написанного на HQL, тем более настроить его производительность.


вот как ORM фраймворк спасет меня в случае если мне нужно написать такой запрос:





powerOn, есть опыт безболезненного переноса?

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


Нет опыта болезненного переноса.   

Задача ORM - укладывать в базу и доставать из нее объекты, которыми манипулирует слой бизнес-логики. В Вашем же случае бизнес-логика находится на уровне БД, т.е. объектная модель вырождена. Соответственно использование ORM в данном случае смысла не имеет.

это же вполне стандартная задача...
Тюнинг оэрэмма для oracle. 

powerOn, Shurr, v2v, спасибо. думаю я кое что понял. поправьте плиз если я не прав.

ORM стоит использовать(в порядке приоритета):
1. если есть потребность в ОО представлении данных;
2. если бизнес логика реализуется на апп сервере;
3. что есть надежда на безболезненную смену СУБД в случае необходимости;

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

Добавлено через 1 минуту и 31 секунду

спасибо за честность 

DimW, 
Первые два пункта обязательны, третий - как один из вариантов. Вместо него чаще идет такой плюс ORM, как повышенная скорость разработки с возможностью в будущем подтюнить узкие места, заменив в них автоматический маппинг на ручной (буде такая необходимость возникнет).

А вывод насчет неоправданности в случае логики на БД - да, так и есть.

DimW, поддерживаю вас.

спасибо, хотя бы не чувствую себя не понятым в этой ветке форума.

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

мои выводы:
1. нежелание и неумение вникать в суть поставленной задачи;
к примеру автора топика совсем не заботит что оракл это версионник и ввиду этого обеспечивает большую маштабируемость, но с учетом специфики задачи "соц. сеть" и требованием к системе "У сети будет тяжёлая фото-составляющая", все преимущества оракл летят в некуда, по моему гораздо аффективней использовать мускул и файловую систему для хранения фотографий. складывается впечатление что выбор СУБД был сделан на основе того что он слышал что "оракл это хорошо"
за то он очень озадачен выбором популярных технологий. стадность прям какая то.

2. вера, что скорость разработки увеличивается;
это работает в одном случае, если стоит задача сдать проект, забрать бабло, и забыть.

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

В общем безграмотность на каждом шагу, стыдно господа!

DimW, жестко! может даже грубо.
Но заставили задуматься, за это - спасибо!

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


Это работает в случае, когда производительность системы под большими нагрузками не ставится во главу угла, либо когда БД не является узким местом системы. 
Это работает в бизнесе, когда система нужна на вчера, и в процессе разработки требования меняются с завидной регулярностью. А после запуска такой системы она устаревает с каждым днем, поэтому скорость внесения изменений очень критична.
Вообще, если говорить о поддержке - практически любая система после выхода в продакшн продолжает развиваться, баги правятся, функциональность расширяется. И если справедливо одно из вышеперечисленных условий, то стоимость поддержки и модификации при разумном использовании ORM будет ниже, чем без него. И чем больше, сложнее система, чем чаще в нее требуется вносить изменения - тем заметнее будет выигрыш.

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

Увеличение скорости разработки делается не для этих целей. Главная цель это как можно быстрее вывести рабочий продукт на рынок. Это бизнес. Рабочий продукт это не тот, что работает быстрее всех, а тот что справляется с поставленными задачами.  Лично я бы не стал тратить время и силы на оптимизацию какой-либо части продукта, если в этом нет необходимости. Если запрос выполняется за 0.05 сек и это всех устраивает, то нет смысла тратить дополнительные силы и время (читайте "деньги") на достижение его выполнения за 0.025 сек. Предварительная оптимизация - это известный антипаттерн.




Увеличение производительности работы через железо тоже бывает экономически выгодным. Все зависит от характера проекта, сроков и бюджета. Сделать кластер может быть реально дешевле оптимизации части программы.

я задумываюсь для почти таких же целей взять вместо Hibernate, Ibatis.. НО.. пока изучаю, и смотрю, что и как, и почему..   

Посмотрел(подсмотрел) на Ваш профиль. Исходя из собственного опыта - проблема в мировозрении.
Просто взгляд на вещи с разных строн. "Кривые" зеркала.

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


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


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



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


неоспоримый факт.


поясните плиз что за разные стороны о которых вы говорите и как они противоречат адекватности выбора технологий для конкретной задачи.


если я кого то обидел - прошу прощения.


пожалуйста.

где в той цитате хоть слово про Фаулера???  

ПС спецом для вас выделил ключевые слова ;)

Это сообщение отредактировал(а) seth - 25.9.2008, 09:47

Наверное также говорил и Гейтс...

да ни где, просто попытался на глупое утверждение дать глутый ответ... ;)


спасибо за заботу.

имхо у каждого своя голова на плечах - захотел спросил захотел не спросил - темболее имхо ветка Оракла это не последняя инстанция ;)


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

Добавлено через 1 минуту и 34 секунды

лучше б вы сказали чем глупое утверждение а не глупо отвечали ;)

ПС темболее в последующих постах можно найти схожие с моими мысли у других собеседников ;)

Я не знаю, говорил ли так Гейтс.  



Это ну очень спорное заявление.  Ещё есть сериализация при сетевом обмене (например веб-сервисы), стратегии разграничения транзакции (уровни изоляции), конкурентное выполнение задач. Т.е. не только из одной БД системы состоят. Можно её (БД) затюнить "по самое не могу", но если веб-сервисы будут тормозить, то все старания пройдут даром.

Это сообщение отредактировал(а) powerOn - 25.9.2008, 10:11

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


если бы вы хотябы попытались вникнуть в суть дела, а не выхватывали удобные для вас куски цитат, то поняли бы что я хочу довести до ващего сведения.


примите во внимание что я себя не позиционирую как спеца по всем СУБД, будьте внимательнее.


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


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

А насколько удобно использовать хранимые процедуры для реализации бизнес-логики при работе с распределёнными базами данных?

DimW  нечего демагогию разводить: есть что сказать - все во внимании

вот еще инфа
Сравнение Hibernate (ORM) vs JDBC

И стал самым богатым человеком в мире...


Что-то не о том вы спорите...

Разрабатывая соц сеть, ГЛАВНОЕ, сделать ее интересной. 

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

На что стоит впервую очередь обратить внимание? 
- Идея
- Удобство использования
- дизайн
- продвижение проекта

Технологии вторичны.

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

Если пойти немного дальше - выбор технологий должен учитывать наличие квалифицированных специалистов на рынке труда.

Спасибо, обязательно посмотрю.

Vasay, для зарегистрированных, но вероятно, впоследствии будет добавлена поддержка openid и google authentication.
JSF мы пользоваться не будем, для AJAX скорее всего остановимся на применении jQuery. Те части сайта, которые должны будут индексироваться, будем делать с учётом SEO.


Честно говоря, с дизайном БД мы ещё не полностью определились, но думаю, что некоторая часть бизнес-логики, тесно связанная с информацией будет реализована на PL/SQL, для этого будем использовать инструменты Spring для работы с БД.


Видимо, Вы имели ввиду front end  Мы хотим, чтобы пользовательский интерфейс был как можно проще и "легче", при этом очень важна межплатформенность и кросс-браузерность. Вместе эти требования отметают некоторое количество RIA фреймворков. Однако я не исключаю того, что с усложнением системы появятся элементы интерфейса, которые будет эффективнее реализовать на одном из RIA фреймворков.


Дело вкуса - кому, что интереснее  Скажу по секрету, что есть особенности, которые с большой вероятностью обеспечат и коммерческий успех именно этого проекта ;)


Напротив, это меня очень заботит - теперь, когда я узнал, что Oracle - это версионник. Хотя я ещё не знаю, что это значит, но обязательно выясню 


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


Я, конечно, много раз слышал, что Oracle, это хорошо, но я не меньшее число раз слышал этот отзыв и о том же MySQL. Мой выбор обусловлен вовсе не этим, а тем, что я имею некоторый опыт работы с этой СУБД (хоть и не на высоком уровне, но кое-что понимаю), а так же наличием в команде человека, хорошо разбирающегося в PL/SQL. К тому же, как я уже писал выше в этом посте, часть бизнес-логики будет расположена именно в СУБД в виде пакетов процедур и функций.


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


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


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


Вот сейчас и настала их вторая очередь - после того, как оформились идеи и концепции будущего проекта ;)


Не удосужился - это немного некорректно сказано. Просто выбор я уже сделал, основываясь на своём опыте и опыте своих друзей и знакомых. Но если Вы или кто-нибудь другой аргументированно объясните преимущества для данного проекта какой-либо другой СУБД или хотя бы недостатки Oracle, то свой выбор я изменю.

PS: Всем большое спасибо за дискуссию, читал с интересном и жду продолжения. Стараюсь, по мере сил, учесть все замечания и мнения.

Я говорил лишь разве что о противоречиях человеческих предпочтений.. То что мы лучше всего знаем, то и "толкаем".
Всё это к теме не относится и все споры не о чём (всмысле они вне темы топика - если интересно - можно создать тему в более соответствующем разделе форума), но я думаю Вы почувствовали напряжённость сообщений.
Ну и напоследок.. База данных выбрана, как бы там ни было. А выбор технологии доступа к данным вообще не должен ставиться, нужно выбирать наиболее востребованные, технологичные и гибкие инструменты,  (Hibernate и(или) JPA). В конце концов база - это только хранилище данных, в контексте задачи, а гланое - веб-приложение (не думаю, что потребуется сильно навороченая схема данных), поэтому лучше изначально всё строить "правильно" как принято.

DimW, Том Кайт написал хорошую книгу для СВОЕГО круга, но это не Библия. Хотя на неё молятся. И база данных - это не панацея. Это и есть разные "мировозрения" - молящиеся на Тома и др., как-то перебивающиеся без него. Не нужно впадать в крайности. Если есть вопрос по оправданости использования ORM - я создам отдельную ветку, чтобы захватить его во всей широте !..   
Обсуждение

сорри действительно фронт энд 



ну это было мое маленькое имхо   если вам интересно то я только за 

я вот тоже для фейсбука думаю приложение написать 



вообще технология популярная ведь не потому что кто то сказал что это популярно и все подхватили - а скорее потому что она интересная или обладает некими существенными плюсами или отсутствием альтернатив ;)

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