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

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

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

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


а если широко использовать memcached, то тоже будет не большая не согласованность? 
можно часть логики бд написать, например, на PL/Perl в PostgreSQL и там управлять  memcached... ? 

Это сообщение отредактировал(а) gcc - 15.11.2010, 14:08

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

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

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

Передача в саппорт  или же передача самого саппорта - есть суть смена и организации и девелоперов. Опять же состав девелоперов и методов девелопмента и технологий деплоймента может меняться, эволюционировать. Како тут избежать бардака? Отсутствие бардака возможно лишь в статике. А статики в этой жизне - мало. Да то не суть. 


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

Отсутствие бардака возможно только при одном истинно вреном источнике (иначе денормализация получается ) - сорс контроле. А так - база всё равно не одна. Допустим, что скрипты для базы не заливаются в сорс контроль. Девелопер1 разрабатывает новую фичу, расширяет какую-нибудь хранимку (добавляет к ней какие-то возможности/параметры и т. д.). Девелопер2 фиксит багу на проде - меняет туж хранимку. Если всё это делается "напрямую в базе", то смёржить это нормально потом нельзя (не, ну можно, конечно, но гораздо сложнее по сравнению с нормальной организацией: всё через сорс контроль).

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

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

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

Был у нас проектик. Его внедрили и сопровождали одни оутсорсеры. Все этапы велись честно. С багртрекером, описаловом всех модификаций, публикацией на сервере контроля версий. Затем они сдали все дела другим оутсорсерам. Сдали честно, всем пакетом документации, консультации и иже с ними. Те нас тоже очень долго оутсорсиили и тоже все по чесноку. Мировые бестпракстис и вся фигня. Дальше от тех аутсорсеров решили отказаться в пользу инхауса. Те сдали дела честно. С примерами, инструкциями, мегабайтами документации и переписок, архивом того, что они получили от предыдущего аутсорсера. Первая попытка самостоятельной модификации одной из форм уперлась в то, что исходник формы, забранный из папочки, где должен бы лежать последний актуальный - тупо не компилится, версия исходника не соответствует версии бинарника. Ктото, когдато отступил от регламента... и поди разбери кто. И то повезло что не скомпилился, было бы хуже если бы скомпилился, но работал не так как след. А экземпляров этой формы всего найдено всего шесть. Вдумчивым анализом из шести удалось выбрать одну, наиболее похожую на правду.
Организационно? конечно это все решается. Но разгребать в конце концов все равно технарям приходится. Жаль что и отгребать тоже. 

Что-т я всё-таки не пойму. При наличии цетнрального репозитория (в случае DVCS всё равно какой-т репозиторий считают "главным") проблемы быть не должно. Или я что-т не так думаю (а вообще, наверно, мы слишком отвлеклись от темы - всё-таки организация рабочего процесса далеко не самый главный фактор).


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

Хранение "кода в базе" тоже не спасает (точнее - тем более не спасает). Никто не гарантирует, что база одна. Обычно энвайронментов много.

Почему не стоит пихать логику в СУБД:
1. Размазывание логики - часть логики будет репрезентативном слое, часть в СУБД. Плюс не совсем понятны зоны ответственности серверов.
2. Тот же PL/SQL или TSQL плохо подходят для реализации действительно больших модулей, да и количество фрейморков под эти языки исчезающе мало. С Java/C# ситуация лучше, но тут тоже есть свои проблемы. Вот у нас например используется Оракл 10, а Java там версии 1.4, и до современной 1.6 ее никак не обновишь. Плюс например тот же Spring не заведется под Ораклом. Куча проблем с деплойментом приложения.
3. Кэширование эффективно не сделаешь.
4. Чтобы увеличить производительность надо докупать лицензии на СУБД, а учитывая сколько стоят процессорные лицензии, то лучше не надо. А если и этого будет мало, то тут придется гемороится с организацией кластера СУБД.



Ну не надо, 99% целостности обеспечивается 3 типами констрейнов: NOT NULL, FK, UNIQUE, и перенести их в другую базу не составит труда.

Есть мнение что целостность и согласованность суть разные вещи, но я таки предпочитаю думать что целостность - лишь один из критериев согласованности.

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

Основное же средство обеспечения согласованности - реализация изоляции транзакций, в MS и Orаcle столь разнятся, что для универсализации разрабу придется забирать этот функционал на себя. А задача эта весьма и весьма не тривиальная, особенно если учитывать требование универсализации. Приложение, где не надо, не должно вставать на блокировках по чтению на MS SQL, а на оракле, наоборот, должно встать, где надо. Именно это, прежде всего, я и имел в виду. 


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

Про TSQL - не спорю.
PL/SQL.... Я уже упоминал что встречался лишь единожды, когда использования жавы было обусловлено сложностью задачи а не предпочтением разработчкика. То был модуль реализации pop3 протокола. 
Тут я действительно не совсем понимаю о чем ты.


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

Никак. Но в приведенном мной сценарии (3-х звенка), подобные вещи делаются средним звеном и на особенности СУБД никак не завязаны. А те 3 типа констрейнов что я упомянул нужны исключительно для избежания проблем при конкурентном доступе.




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




Это все верно, но для сколько нибудь нормального отображения ошибки и показа пользователю она должна быть сгенерирована как можно ближе к модулю отвечающему за представление. Вытаскивать из того же SQLException код ошибки и пытаться понять по нему, что пошло не так - то еще удовольствие. Совсем другое дело, если мы сами перед сохранением проверим все ли требования выполнены.




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




Приведу, но чуть попозже.

Ну да. И если мы будем закладываться на возможность конкурентного доступа к объектам системы, то нам придется самостоятельно обеспечивать изоляцию. В том же примере про документ, который не должен быть сохранен в случае ошибочного оформления, мы ведь должны как то учитывать что в процессе проверки и до момента его сохранения состояние и критерии не были изменены конкурирующим процессом. Потому нам придется средствами приложения раскидывать блокировки - забирать на себя реализацию изоляции транзакций. О чем я и толкую.

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

Тут палка о двух концах. Я, конечно, не совсем в теме. Особо не копал, но что нарыл, то нарыл. В жавьем концепте, простейшее уточнение структуры данных, как правило требует модификации  бинов, зачастую - куда более одного. Желание производить эти рутинные операции автоматически вполне оправдано, потому жава и обросла огромнейшим арсеналом средств рефакторинга.
Что же касается различных наборов библиотек.... я уже упоминал что 99,9% прикладной логики энтерпайза - выбрать данные и сохранить результат. Мне действительно не доводилось встечаться с потребностью в обилии библиотек. И я уже упоминал, если прикладная логика имеет действительно сложную алгоритмику, ее вынос на выделенный сервер приложений вполне обоснована. Но я уже пять лет автоматизирую процессы предприятия и мне все еще такая логика не встретилась. Хотя, право же, действительно хотелось бы обосновать необходимость реализации прикладного слоя на жаве и получить новые компетенции.

Еще с одним недостатком реализации логики средствами приложения мне доводилось сталкиваться. Приходили к нам парни, крупные международники, внедряли крупную, дорогую, систему, интегрировали ее с прочим ###м, что у нас имеет место крутиться. Получилось так, что за интеграцию с разными модулями отвечали разные команды, а единый прикладной слой толи не был выделен, толи инструментарий не позволял его использовать(жава+формс). В результате получилось что в одну таблицу, разными интерфейсами сливаются документы из разных систем. И в каждом интерфейсе реализуется логика. И в некоторых она была реализована по разному. В результате мы получили систему, в которой не обеспечена согласованность данных. Данные о транзакциях не соответствуют данным об остатках, потому как документы одного типа были отражены в остатках разными способами. Вынос прикладной логики на сторону бд, позволил бы избежать этой ситуации. Если же реализовывать средствами апп.... Думаю, вполне можно было бы создать некий жава класс, который реализовывал бы эту самую необходимую логику, однако я не уверен что работать с ним было бы проще нежели работать с таблицей и не уверен, что его можно было бы сколь нибудь просто использовать из формсов, и так же не уверен, что нам бы не пришлось таки дублировать часть логики при работе с этим классом, дабы потом не анализировать уже не SQL, а java exception.

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

заранее благодарен 

Это сообщение отредактировал(а) Zloxa - 24.11.2010, 15:46

1. Блокировки можно возложить на ORM, если мы хотим их делать на уровне СУБД.
2. Можно использовать версионирование (средствами того же ORM) и обойтись вообще без блокировок.
3. Для совсем "запущенных" случаев, никто не отменяет блокировки на уровне сервера приложений.
4. Или даже сделать небольшой СУБД зависимый модуль. В любом лучше переписать один маленький модуль, не представляет большой проблемы.
Хотя лично мне в моих приложениях всегда хватало commit/rollback. Пару раз приходилось использовать блокировки на уровне ORM и версионирование.



Ну а теперь смотри: у нас есть логика проверки согласованности данных в слое представления и точно такая же в СУБД. Профит в том чтобы держать ее и там и там я вижу только один: если какая-то сволочь залезет в базу напрямую, то данные все равно будут согласованны. Но мы же понимаем, что кроме DBA никто так делать не будет. Зато мы получаем необходимость держать эти две реализации логики проверки в согласованном состоянии.



Тут дело не только в переименовании, там еще куча всего типа выделить из класса интерфейс и заменить использование класса на использование интерфейса, заменить непосредственное создание на фабрику, окружить блок try/catch-ем и т.д. И это касается не только Java для C# тоже рефакторинг весьма богатый: IDEA Refactorings, ReSharper Refactorings. К тому же рефакторинг это не единственная фишка, там есть и анализ кода на лету, т.е. в той же IDEA мне не нужно запускать компиляцию, чтобы узнать что у меня в коде есть синтаксические ошибки. Интеллектуальный поиск по коду (find usage, call hierarchy и т.д.). Автоматическая генерация кода.




Я не говорю что их надо много, но часто бывают специфические требования типа работа с SCP, связь с другой системой через SOAP и т.д. Ну и плюс всякие мелкие утилитки, типа логгирования, коллекций и т.д.
И еще я говорил про утилиты для build lifecycle, как-то сборка, тестирование, деплой, что может предложить PL/SQL?




Это частный случай неудачной реализации. А представь в какую позу встала бы база, если бы эти альтернативно одаренные внедренцы попытались бы засунуть логику в СУБД (каждый свою собственную)  


P.S. Предлагаю тестик реализовать проверку корректности Номера банковской карты на PL/SQL и Java соответственно, номер приходит как строка.

Готов поменять свое мнение.

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

Мне необходимо локализовать проблему. Пытаюсь трассировать этот процесс. Открыаю фронт прикладухи, готовлю объект, запускаю скрипт, который переводит все активные сессии в режим трассировки и взводит триггер на онлогон, включающий трассировку для новых сессий. Нажимаю педаль утвердить, жду пару секунд, получаю респонз от от апп, подтверждающий отсутствие провтиворечий, отключаю трассировку. На сервере я один. Лезу в трассы... вижу там 25(!!!) многомегабайтных файлов трассировки. Т.е. в этом процессе поучаствовали 25 сессий. Пулл коннектов - браво! Это же просто шикарно. Я уже на эту задачу убил 10 часов, результат пока 0. Если я таки локализую эту проблему, я на ней столько бабла подниму - жена уже пакует чемоданы на Кипр. Если бы были не правильно выбраны технологии, я на задачу потратил бы от силы 2-4 часа.

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

Мы ЕАНы чекаем PL/SQLем. Чтобы эта процедура когда нибудь оказывалась узким местом - не могу припомнить.

Это сообщение отредактировал(а) Zloxa - 4.12.2010, 18:42

Я не про производительность. Просто мне кажется, что на PL/SQL код будет более громоздким. Во всяком случае когда я пытался нечто подобное реализовать на PL/SQL то код получился довольно громоздким.



По поводу привести пару примеров:

Если у нас 3-х звенка то выбор стратегий кеширования достаточно широк: 
а) можно просто полагаться на кеш базы
б) можно перед СУБД поставить кеширующие сервера (например Memcached), причем их количество можно безболезнено наращивать
в) можно внутри приложения использовать собственное кеширование загруженных данных и результатов вычислений
г) можно делать кеширование данных для клиентов (например сгенерированных HTML)
Если же у нас сервер приложений отвечает только за результат, то остается только а) и г). Пункт б) выпадает по понятным причинам, в) же нельзя использовать потому что не имея в слое представления бизнес логики, нет возможности корректно инвалидировать данные в кеше.
Приведу пример: есть система управления правами типа Oracle Entitlements Server, у нас есть юзер, права и роли. Чаще всего нам будет нужно для пользователя получить список его прав и проверить, есть ли у него право на некое действие/объект, так что кешировать связку человек-права вполне стоит. А теперь представь, что мы в роль добавляем еще одно право. Нам надо как минимум инвалидировать закешированные для некоторых пользователей права, а еще лучше перевычислить их. Если у нас бизнес логика в сервере приложений, то проблем нет, мы знаем как это сделать. А вот если она в СУБД, то тут уже придется помучится.





Большая часть запросов к системе идет на чтение и читающие запросы достаточно легко распараллеливаются. Поднимаем 10 бесплатных Томкатов, ставим перед ними балансировщик, поднять стендбай и у нас готово дешевое решение. А если бы мы попытались тоже самое реализовать с Ораклом, нам пришлось бы купить лицензию на Oracle RAC, потратится на SAN для RAC, ну и конечно поднять 10 Томкатов  (слой представления никуда же не делся).

LSD, спасибо за интересный ответ по существу. Определенно это материал для раздумий.

Из того, что приходит в голову на вскидку, без глубоких размышлений:

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


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

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

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



1. Как это реализовать в Оракле без использования Явы?
2. Т.е. у нас получается, что СУБД (в данном случае это слой которой содержит бизнес логику) завязывается на слой представления.

dbms_alert- бомба вещь.

Нет, он не завязыается. Это просто средство оповещения всех заинтересованных сторон. Процесс, сигналящий алерт не знает, слушает ли его кто. 

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



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

Будет несогласованость по чтению: репликация штука не моментальная. Это неплохо делать для аналитики, но для боевого OLTP бессмысленно - тут только RAC.

Это сообщение отредактировал(а) ToshaCh - 8.12.2010, 10:06

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



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

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


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

Добавлено @ 17:58
В смысле я себе представляю кэширование как разделяемый поцессами приложения ассоциативный массив.
Возможно его можно реализовать еще какими то способами, и тогда, действительно его реализация может оказаться проблематичной.

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

Вот и я так подумал.

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


Я пробовал такое реализовать. Боевая база работает по OLTP, а физический стендбай открыт для чтения (плюшка у 11g) для построения адских отчётов. Главная проблема с которой я столкнулся это устаревшие данные: на OLTP они уже не нужны, а для аналитики необходимы. Соответственно возникают грабли с производительностью. Следовательно нужен более умный перенос данных и его, на мой взгляд, логичнее делать имено на уровне базы.

Пользуясь тем что "в интернете опять кто-то неправ" хочу поднять тему  

А как организовать unit и интеграционные тесты в СУБД?

Откуда дровишки?

Ты о чем?

Имелось ввиду: так кто же не прав в инете? Те ссылку.   

Вроде что-то такое слышал есть...

Средствами реализации тестового сценария.

А что вообще имеет смысл тестировать?

Zloxa срывает покровы.




Капитан, мы жаждем подробностей  

Мы тоже. 

Чувствую долго ждать придется.

Ну это же твой наборос.

Взялся бросать - не говори что не дюж.

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

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

Это сообщение отредактировал(а) Zloxa - 29.7.2011, 14:41

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




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

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

Это сообщение отредактировал(а) Zloxa - 29.7.2011, 14:55

Зачем нужны юнит тесты, часть 1
Зачем нужны юнит тесты, часть 2

LSD, не смотря на то что букав много, я стоически их осилил полностью. Все ждал когда мне откроется сокровенное. 

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

Я совсем не понимаю, о чем ты говоришь, когда говоришь что тестировать возможности нет.

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

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

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

Да, это выход. И такой подход одинаково применим как к прикадной логике на pl/sql, так и к логике на жаве.

полуоффтоп.

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

И еще. Поможет ли инструментарий юнит тестов, дать заключение о корректности поведения тестирования модуля в конкурентной среде?

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




Ты не правильно понимаешь суть юнит тестирования. Юнит тестирование не отменяет интеграционного и user acceptance testing, а просто дополняет его. Юнит тест тестирует маленький функциональный компонент (например класс) в изолированной среде, на предмет выполнения этим компонентом формального контракта. Смысл юнит тестов, это раннее обнаружение отклонений поведения компонента от контракта. И поэтому юнит тесты обычно запускаются во время сборки проекта.

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





Я вообще не понимаю о чем ты  Приведи пример.

Точно так же. Пишется на коленочках суррогатный тестовый сценарий, контролируется результат его работы. Прогоняется по мере реализации. Механизм запустить такие сценарии  при сборке мне не известны. Впрочем и механизм сборки как таковой, тут отсутствует. Здесь специфика такова, что процедура одновременно и компилируется, и деплоится, при этом ревалидируются зависимые объекты. Потому, собственно, нужды в суррогатной среде исполнения, позволяющей потестить до деплоя - особо нет. Такой средой выступает непосредственно девелоперское окружение. После получения стабильной версии кода, он переносится на тестовое окружение, где проводятся пользовательское тестирование и тестирование интеграции. Затем, если все ок, код перезжает на продуктив.

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


Самый простой пример взаимной блокировки - когда процесс1, удерживающий блокировку ресурса А пытается захватить ресурс Б, удерживаемый процессом 2, который в то же самое время пытается захватить ресурс А. 

У оракла есть какая-то процедура, позволяющая отслеживать взимные блокирвоки. У МС, емнип - тоже. В случае обнаружения попытки взаимной блокировки, одна из сессий прерывается. Иначе у нас существует громадный риск что приложение встанет колом. Винда, как я помню, не следит за дедлоками. Следит ли жава - не знаю, не слыхал.   Потому - спрашиваю


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

Потоки JVM не убивает, но дедлоки детектит и можно программно их обнаружить (и прибить, если захочется).

стыдно признаться, но про result_cashe узнал лишь недавно.

На сколько я понял резалт кэш может быть настроен как для pl/sql функции, так и для запроса. Резалткэш функции сбрасывается при коммите в таблицу, указанной в RELIES_ON. Для запроса, пока еще не понял, пока из статей остается ощущение, что резалткэш запросов не сбрасывается а обновляется при коммите в целевую табилцу. Гранулярность резалт кэша - инстанс датабазы, т.е. в отличи от модели кэширования которую я предлагал ранее (с кэшированием в глобальных пакетных переменных и сбросом по алерту), работает не только для одной сессии, а для всех сессий, которые попадают на этот инстанс.

Мне кажется что эта фича аккурат для твоего примера.

Это сообщение отредактировал(а) Zloxa - 4.7.2013, 15:39

При реализации навороченных исчислений на базе данных оракл или другой, лучшим выбором будет реализация с помощью встроенного в базу данных инструмента, такого как pl/sql или java в виде Stored Procedures. На оракл, хранимые процедуры можно писать и на Java. Производительность системы написанной с помощью хранимых процедур будет более высокой за счёт того, что код и данные будут на одной и той-же машине. Мне приходилось работать с системами где было необходимо реализовать вычисление различных коэффициентов и статистики на основе данных в таблицах. Перенос логики в PL/SQL в десятки раз ускорил операции. Когда код начали крутить на онлайновой системе, DBA не могли поверить, что расчёты стали выполнятся мгновенно. Исполнение кода процедур внутри процесса базы данных очень сильно ускоряет расчёты. И не важно на java написана процедура или на PL/SQL. 

Что-же касается ORM, то он хорош для CRUD операций с клиентских машин или веб-серверов. Делать системы сложных расчётов на ORM - это стрелять себе в ногу.

dobrolub, пардон, ко.   

Я в основном говорил про im memory cache, не дисковый. Т.е. поднимаем сотню дешевы серверов которые в памяти держат данные и отдают по запросу.

Это и есть инмемори.  В SGA инстанса.