web_foxВам же про фотошоп аналогию привели. Её поняли все на форуме, кроме вас.
- поняли все DBA, которые бездумно используют PL/SQL, предназначенный для автоматизации реляционных преобразований, также как и дизайнеры профессионально владеющие Photoshop используют JavaScript для автоматизации графических преобразований? Кстати, если бла-бла про продукт который Вы не знаете (Photoshop) Вам показалось остроумным - ознакомьтесь с возможностями продукта который Вы знаете? - Oracle Spatial

web_foxЕщё один отличительный признак: всех, кто знает PL/SQL он называет DBA. Будьте осторожны на улице, он может жить в вашем городе.
- кстати, просвятите как их называть? Симптомы: без БД Oracle ничего сделать не может (в том числе и на других базах), пишет бизнес-ориентированную логику на PL/SQL, не программист, но уверенно рассуждает о недостатках ORM и Java. Некоторые экземпляры отличаются неумением вести разумные дискуссии и легко переходят на личности. Что касается шуток на тему "осторожности на улице" - я в отличие от многих моих оппонентов не скрываюсь за анонимной подписью и все кому моя точка зрения чем-то не нравится могут запросто обойти меня сторонкой не привлекая к себе внимания ;)

web_fox1. ORM в отличии от СУБД позволяет кешировать лучше.
2. Java в отличии от процедурного ЯП СУБД работает быстрее. Попробуйте выполнить в транзакции 1000 merge для объекта в ORM и 1000 update в БД и сравните производительность.
3. В реальном приложении не нужны реляционные данные, оно оперирует бизнесориентированными объектами, по работе с которыми и надо судить о производительности.
4. Java-код масштабируется дешевле и проще чем СУБД.

- все верно сформулировали (спасибо за внимательное изучение некоторых из моих высказываний на тему ORM и достаточно аккуратное их изложение), только во 2 пункте не все понятно - я бы под ним подписался, если бы речь шла об одной транзакции в рамках которой выполняются операции и слово "Java" (это ЯП) заменил бы на ORM (это он быстро выполняет операции над данными загруженными в ОП, а сам ORM может быть реализован на различных ЯП). Какие-то пункты (например 1, где слово "лучше" можно трактовать как угодно или слово "не нужны" в п. 3) можно было бы развернуть, чтобы не провоцировать бессмысленный агрессивный флуд. Также где-то писал что ORM обычно дают возможность выполнения нативных SQL-запросов и в задачах требующих редкой обработки больших массивов данных (составление годового отчета) эту возможность никто не запрещает использовать.

GarrickВы рассуждаете с точки зрения программиста - вам удобнее писать на чём-то не PL/SQL.
- именно эту точку зрения я и пытаюсь донести: PL/SQL по сравнению с другими языками программирования не удобен, а бизнес-логика это не 3 строчки кода, в связи с чем разработка развитого приложения требует комманды программистов, удобных инструментов разработки и отладки, и т. д. (об этом написано много разных книг). Можно спорить на тему что удобней для написания бизнес приложений: C#, Java, Python, Delphi и т. д., но добавить в этот список PL/SQL просто невозможно - это как вместе с лошадьми сравнивать стати ишака, который эффективно решает возложенные на него задачи, но требовать от которого победы в дерби просто смешно.

lockyодин мой коллега как-то сказал: "ОРМ дает возможность программисту, совершенно не разбирающемуся в СУБД, написать приложения для работы с БД"
- чепуха, использование ORM, как минимум требует навыков работы с транзакциями и уровнями изоляции транзакций СУБД, а также знания SQL на уровне уверенного использования оператора JOIN, в противном случае даже элементарных вещей с помощью ORM сделать скорее всего не удастся

lockyОткуда, собстенно, и начинаются все проблемы.
- согласен

lockyпорадовал до слёз
- я слабый телепат, хотите что-то сказать - говорите

lockyВозможно, я ошибаюсь, но ежели нет - то такой подход меня радует до слёз.
- давайте закончим с телепатией - я не говорил что должно быть две способа генерации отчетов, суть моего тезиса: наличие ORM не лишает возможности использования нативных SQL-запросов в тех случаях в которых это может показаться необходимым архитектору системы. Моя личная точка зрения - обработки больших объемов данных (таких которые система не может обработать за приемлемое время) вообще быть не должно, если такая задача/проблема возникает это говорит о неправильной (не соответствующей фактическим требованиям) архитектуре приложения/базы не учитывающей особенностей бизнес процесса (вот гоблины сейчас начнут надо мной глумиться).

PanshinKachalovМоя личная точка зрения - обработки больших объемов данных(таких которые система не может обработать за приемлемое время) вообще быть не должно
Я бы не стал так говорить. Не должно быть таких систем, которые за приемлемое время не могут обработать большие объемы данных. Хочу спросить знает ли кто как идет обработка телефонных звонков в биллинговых системах? Ведь там ежечасно нужно обрабатывать миллионы записей иначе большие объемы данных.
- давайте доведем ситуацию до абсурда: у Вас имеется таблица в которой хранятся данные биллинга абонентов РФ за 5 лет, т. е. заведомо обработка такого массива данных не реальна, следовательно надо проанализировать задачу и решить: необходимо ли работать одновременно со всеми данными из этой таблицы? т. е. актуальны ли хранимые в ней данные. Ответ очевиден - в большинстве случаев иметь доступ ко всем данным за 5 лет или по всем регионам РФ нет необходимости. Более подробно о возможном решении задачи в Гугле - партиционирование (partitioning).

Kachalovпартиционирование (partitioning).
- забыл добавить, что мне кажется более логичным когда задача партиционирования ложится не на СУБД, а на архитектора проекта, который исходя из предполагаемого объема данных и связанных с ними задач осуществляет партиционирование на этапе планирования структуры данных

lockyну и причем тут, простите, партиционирование?
В намечающемся противостоянии "логика в хп" - "логика вне хп"?
- весь Мир сошел с ума? или Panshin это то же самое что и locky ?

lockyдругие аргументы?
- кто здесь? чего Вам от меня-то надо?

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