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



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 сек. Предварительная оптимизация - это известный антипаттерн.




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