По мотивам обсуждения тема.

Как грится - кому что по душе и лучше обосновано плюсы и минусы подходов!

ps. Почему pl/sql - там чаще всего наворачиваются мощные супер системы.

Это сообщение отредактировал(а) serger - 25.9.2008, 17:15

По чистой производительности PL/SQL сильно уступает Java (по заявлениям самого Oracle). Плюс многие вещи на PL/SQL надо делать через одно место.

Единствено когда PL/SQL лучше, это реализация хитрых запросов, которые "невыразимы" SQL-ем. И вообще ситуации, когда SQL сотавляет основную часть логики работы процедуры.

А вообще холивар пустой, ибо сравниваются совершенно разные вещи.

наверное потому что большие объемы данных и сложные бизнес правила обрабатывающие эти самые объемы и возвращающие малое кол-во данных 
т.е. экономия траффика и времени на передачу данных

Добавлено @ 17:47


имелось ввиду скорее
обработка данных в приложении  + обработка данных в БД чем просто ORM vs JDBC

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

Почему я выбрал такое сравнение.

Том Кайта читали? Хотя бы вступление? Извините за несколько фамильярный стиль, однако немного прёт... (пятница, пиво...)
Там приводится пример, почему не нужно забывать про БД. Мифическая компания разработала JEE приложение,по всем правилам и тп, но столкнулась с проблемой быстродействия. БД видете-ли тормозила. Позвали специалиста, тот сказал - типа вы с БД не умеите работать, надо это исправить! Ну пиво или там чай - все принялись за дело и УХ!... ЦЕЛЫХ две недели тюнили БД. Беда-то какая!!!

Я не буду писать свои выводы, с датами тоже мог ошибиться, но не намного и это ИМХО не существенно. Просто предлагаю задуматься, что это значит, ну и поспорить..

ps, всё-таки на счёт логики будет несколько банально спорить.. Ну и по позже напишу, что сам думаю, если нек поменяю своё мнение.. ;)

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

Хотел создать похожую тему, поиск подсказал что тема уже обсуждалась.
Жаль что тема не развилась. Мне было бы ОЧЕНЬ интересно почитать доводы сторон.
Удастся ли возобновить обсуждение?

На тему стал интенсивно задумываться после публикации линка на ЖЖ в теме "Извините за офтоп. Просто посмеяться" в ораклином подразделе на sql.ru, с коментарием "ЖЖшные леминги обсуждают Oracle". Есесно ораклиное сообщество оборжало высказанные там мысли.

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

Что надумал:

Вынос прикладного слоя на выделеный сервер приложений, для меня, безусловно, необходим в случаях:
1) Платформа СУБД не представляет сколь нибудь удобного инструментария для реализации прикладной логики
2) Прикладная логика весьма увесиста и требует много вычислительных ресурсов
3) Абстрагирование от платформы СУБД.

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

*1
К первому пункту я безусловно отношу такие платформы как MySQL, Fb, MS Sql(хотя я не знаю как там сейчас обстоят дела, вроде как они уж прикрутили clr, возможно это чтото изменило, но на tsql сколь нибудь замороченную прикладную логику реализовать - мазохизм)

К ораклу первй пункт применить сложно. PL/SQL достаточно развитый язык, на нем действительно можно чтото написать. Он позволяет поднимать и обрабатывать исключения, ограничивать область видимости функций, определять глобальные переменные и константы. Есть даже, хоть и куцая, объектная модель, полиморфные свойства которой вполне можно использовать. Где не хватает PL/SQL, можно прикрутить жаву (но на моей парактике я встечал лишь единожды, когда применение жавы было обусловлено сложностью задачи а не предпочтением разработчика)

*2
Действительно увесистая прикладная логика встречается весьма редко. Мне она вообще ни разу не встречалась. Мне не приходилось конвертить картинки, видео, шифоровать, паковать, распаковывать. 99,9(9)% прикладной логики, с какой мне доводилось сталкиваться и реализовывать - подсмотреть какието данные в базе, на основании их принять решение и сохранить его в качестве результата либо поднять исключение. Т.е. большая часть вычислительного ресурса тратится на доступ к данным. Разбор XML, пожалуй, самый трудоемкий, с точки зрения нагрузки на проц, процесс, который не связан с доступом к данным и который мне доводилось использовать при реализации прикладной логики. 99,9(9)% циклов, реализованных мною предназначены для обхода курсора, не для иттерационных вычислений.

*3
Это исключительно маркетинговая фишка. Любой вменяемый технический специалист будет отбрыкиваться всеми доступными ему средствами от желаний маркетологов скрестить лопату с микроскопом. Средства обеспечения согласованности данных в MS SQL и Оракле настолько различны, что технарю придется забрать на себя львиную долю забот, которые можно было бы возложить на СУБД. Когда этот довод звучит из уст технаря, я недоумеваю.

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

Однако. Что меня заставляет усомниться. Оракл не стремится развивать свой PL/SQL и он направил свои усилия на развитие своего app. Т.е. видение самой oracle corp в том, что прикладная логика таки должна реализовываться гдето сбоку.

Мне это нихрена не понятно. Я это очень хотел бы понять. Я не вижу никаких приемуществ выноса прикладной логики на аpp, иных кроме "это круто", "это сложно", "заказчик офигеет и не станет сомневаться  достаточности длины нашего перца". Эти тезисы имеют место быть, но они не технические. Когда я роюсь в исходниках того же oracle corp, что я вижу? Я вижу что часть прикладной логики они реализуют в формах, а часть - на датабазе. Зачастую это одна и та же логика. Это же вообще швах. Не, я понимаю, что они на датабазу сливают тот функционал, который может быть востребован не только их апп, но и другими приложениеми. Но нафига нужен такой апп, если все равно часть логики приходится сливать на бд? Я так полагаю что если у нас прикладную логику реализует апп, то все импорты, конверсии, сопряжения со сторонними модулями должны идти исключительно и только через него. Если это напряжно, трудоемко... тогда бизнеслогику  держим на стороне бд и баста.

Это сообщение отредактировал(а) Zloxa - 11.11.2010, 17:05

тут еще была похожая тема
http://forum.vingrad.ru/index.php?showtopi...t&p=2024681



СУБД умеет как-то конвертировать картинки?

Это сообщение отредактировал(а) gcc - 11.11.2010, 13:02

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

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

Это сообщение отредактировал(а) Zloxa - 11.11.2010, 16:27

ПРО ORM
- если приложение - это админка, где есть много запросов маленьких через Ajax, то как раз удобно тут применить ORM?
т.е. получается сложных запросов нету, а везде такие на подобе select id from table id = 1

- ORM дает кроссплатформенность между СУБД, можно выбрать любую (некоторые дают возможность использовать LDAP)

- защита от инъекций, при настройке ORM расставляется типы столбцов и сразу стоит защита от инъекций к конкретному типу столбцу 

- ORM удобный:
wikipedia



при обрабоке данных красиво получается на CRUD, разные обработчики форм, обрабатывают и строят запрос INSERT UPDATE
да, кроме ORM есть другие абстракции Rose:B или где INSERT UPDATE генерируются с помощью классов, а SELECT в нативном виде...


НО и есть такае запросы которые НЕ написать на ORM и даже на чистом SQL, то приходится использовать ТОЛЬКО plpgsql ? 
где очень сложная логика в триггерах и процедур на PostgreSQL...



Это сообщение отредактировал(а) gcc - 12.11.2010, 18:25

Реализация прикладной логики на стороне бд ни коим образом не препятствует использованию ОРМ для реализации репрезентативного слоя.

Добавлено через 7 минут и 55 секунд
Хотя... возможно вру.
Я правильно припоминаю что некоторые ОРМ кэшируют данные и, если данные были модифицированы мимо этих ОРМ, они теряют согласованность?

Это сообщение отредактировал(а) Zloxa - 12.11.2010, 20:11

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

По теме против "логики на хранимках" приходят в голову следующии соображения:

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

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

Недопущение концентрации компетенций в одном ресурсе это управленческая проблема - не техническая.

Но тут... конечно мое мнение субъективно, но реализованная средставами БД логика, как правило, имеет легко выявляемые жесткие связи, что позволяет разобраться в ней куда проще, нежели в никак не связанных svn, war и бд. Это, конечно более характерно для саппорта, нежели девелопмента. Стык девелопмента с саппортом, как правило, имеет много организационных лакун. Логику, реализованную в бд, мне кажется, намного проще забрать на саппорт ввиду ее гомогенности.

Да, у меня были мысли относительно того, что один апп может держать одновременный коннект многим бд.
Тут две ветки рассуждений
1) Апп может работать с разнородными БД. В этом случае апп выступает в роли надстройки и пользует интерфейсные функции прикладного слоя, который с тем же успехом может быть реализован ХП.
2) Апп может работать с однородными БД, распределяя нагрузку между ними. Тогда апп действительно придется на себя забрать огромный ломоть прикладной логики. Но, вместе с тем, придется на себя забирать и обеспечение согласованности данных между разными инстансами - имхо весьма, и весьма скользкая и ответственная задача.

Для реализации этого самого горизонтального масштабирования средствами БД, если там применим воркфлоу подход, вполне может оказаться пригодной технология Oracle streams AQ

Это сообщение отредактировал(а) Zloxa - 15.11.2010, 11:32

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

Это сообщение отредактировал(а) Zloxa - 15.11.2010, 11:57

Ну.. Просто со статистикой приходиться мириться. Людей хорошо разбирающихся в базах мало.


Не понял, что это значит.


Я имел ввиду в первую очередь этот кейс. У нас возросло на порядок количество юзеров и мы справляемся с этим, просто добавив машины (ну, я условно).


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

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

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

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

Это сообщение отредактировал(а) Zloxa - 15.11.2010, 12:50