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

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

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

Добавлено через 3 минуты и 12 секунд
Вот многие мои знакомые делфисты, кстати, чураются реализовывать логику работы с данными средствами делфи. И кто, спрашивается, после этого овнокодер?

Что значит оперирует непосредственно данными? Я думал что 90% кода как раз занимаются тем что оперируют данными, а оставшийся код обслуживает эти 90%.



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

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

И кстати, я тоже чураюсь реализовывать логику работы с данными средствами дельфи 

Добавлено через 9 минут и 45 секунд
Вспомнил историю из жизни: есть у нас некая система которая хранит и обрабатывает некие данные. Мы ей шлем запрос сделай мне то-то и то-то, система проверяет входные данные и делает что велено. Все проверки сделаны тригерами. А тут клиентам захотелось странного, чтобы проверять пользовательский ввод до того как он нажал Submit, и показывать сообщение об ошибке. Будь эта логика не в СУБД мы бы это легко реализовали, а так жди пока они все вытащат этот код из тригеров.

Да, у нас логика на столько простая, что спокойно реализуется на PL/SQL.
И вынос на выделенный сервер приложений ее многократ усложнит. И тогда та же логика станет действительно сложной. Сложной станет как в разработке, так и при эксплуатации.   

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

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

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

Все остальное в этом модуле - обвяз. Принять по AQ XML со списком товар+размещение, по которым должен произвестись расчет, посчитать для каждого товара скорость, упаковать в XML результат+сопутствующую статистику, отдать результат тем же AQ.


Менее пятисот строк. Глянул, из них не менее ста - коментарии и закоментированные фрагменты кода, так что - все четыреста.
Действительно все достаточно просто. Но, боюсь, реализация того же самого функционала средствами жавы оказалась бы куда менее проста и лаконична. А елси бы для доступа к данным использовался ОРМ, боюсь это было бы еще и неадекватно ресурсоемко.

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

Надеюсь дельфисты поняли  

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

И что? Из Java нельзя выполнить этот запрос? Или я где-то утверждал, что нельзя использовать SQL там где это нужно/удобно?

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

Что же касается кода в триггерах, то радуйтесь что у вас он есть. Радуйтесь, что как бы вы не накосячили со своим контроллем ввода, логику стороннего приложения(не отключая, конечно триггеров), вы не закривите. У нас вон, есть на жаве писаный Oracle RPM(Retail Price Management). И бизнес нас просит подлить туда правила ценообразования для 20 магазинов о 150тыщ наименований товаров в каждом. А мы не можем. Исходный код закрыт, логика не описана, если хибер сочтет что целостность данных нарушена, RPM просто перестает работать. Понять чего ему не хватает можно только трассировкой, которая очень усложняется тем, что используется пулл коннектов. Бизнесу придется ручками эти данные херачить.

Добавлено @ 16:52

Можно. Но из PL/SQL выполнять этот запрос - удобнее. Мне кажется правильным было бы - завернуть этот запрос в пакетик и дернуть его из жавы. Но это уже размазывание логики. Нет?

Но и опять же, в чем профит тут тогда от использования жавы? Где пресловутая абстракция от БД?

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

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




Чем?



Абстракция будет если использовать простой select без специфичных фишек оракла.

Фиксацией связи с объектами схемы.
Синтаксическим анализом на этапе компиляции, а не исполнения.
Возможностью влиять на план запроса без пересборки приложения.

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


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

Если мы подобный запрос пустим на блокировочнике вроде MS SQL в режиме изоляции read commited, на время исполнения он блокирует регистры остатков. Прочие приложения, двигающие по остаткам - встанут колом. Да и сам запрос может встать на блокировке. Могут случиться взаимные блокировки. Результат будет получен согласованным на момент окончания работы стейтмета. А оракл никого не заблокирует, и сам на блокировке не встанет. Результат будет согласованным на момент начала работы стейтмента. Для версионников и  блокировочников таки нужен несколько разный подход при решении однотипных задач. 

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


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


Я тоже так считаю.
И лучше чем база - место сложно придумать.

И пофиг будет ли писать в базу дерзкий студент жавапис, матерый ли, но мудаковатый делфист, харизматичный ли индус-формсист, или же дешевый суппортер, с базовыми навыками sql, получивший заявку "удалить накладную" на сервисдеск, от своевременного исполнения которой зависит его KPI. Никто из них не должен иметь возможность закривить данные, нарушить логику приложения, а суппортер таки должен получить бонусную часть своей и без того крохотной зарплаты, начисляемой по KPI.   

Это сообщение отредактировал(а) Zloxa - 13.2.2012, 19:44

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



1. Ты слишком преувеличиваешь проблему взаимных блокировок. Я вот за все время ни разу не сталкивался с подобными проблемами.
2. Абстрагирование это не поменять настройки конекта, и опа мы уже работаем с MS SQL вместо Оракла. Это возможность портировать приложение с Оракла на MS SQL с минимальными усилиями. А если вам хочется полной независимости от СУБД, то тут конечно придется свести взаимодействие к примитивным селектам.



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




Ты слишком базоориентирован  Ты исходишь из того, что все крутится вокруг базы и все должны на нее молиться. А жизнь, то она разнообразнее 
У нас есть система персистит данные в memory mapped file, и потом отдельный процесс неспешно разгребает это все и сохраняет в базу. В работе системы база не участвует, она нужна для архива. Есть другая система которая представляет из себя большой Oracle Coherence кластер, в который сохраняются данные и в нем же происходит агрегации и другие вычисления, база тут тоже задействована исключительно для архивных функций.

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

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

Если мы интегрируемая с внешней системой средствами XML, мы ведь имеем ту же самую картинку. Если на той стороне изменится спецификация обмена, нам будет предоставлен измененный XSD, по которому завсегда мы можем регенернуть врапер и все места, где нам следует что-то предпринять тут же разметятся в коде красными выделениями. Почему желать подобного от связки с БД, ты находишь странным?


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

О том что запрос может рубануться по дедлоку упомянул потому лишь, что между делом об этом подумалось. Впрочем, оракл тоже может рубануть запрос по snapshot too old.


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

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


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


Я не отрицаю, что существуют случаи, когда решение на жаве оказывается предпочтительнее связки Delphi + PL/SQL. Но я работаю в этой связке и смотрю с этой колокольни. Мое признание вовсе не означает что в  результате замены этой связки на жаву, даже при условии следованиям паттерннам и бестпрактикам, будет получен сколь нибудь ощутимый профит. На данном этапе своего личностного развития, я скорее ожидаю обратного. Причем по той самой причине, которую ты озвучил, как причину нелюбви к делфи. Жава, вероятно от избыточной гибкости, для придания общей конструкции определенной прочности, требует следования паттернам и практикам, вынуждая тем самым отказ от использования смежных технологий, способных решать задачи более эффективно, провоцируя тем самым велосипедирование и овнокодинг.

Это сообщение отредактировал(а) Zloxa - 15.2.2012, 10:08

А вьюхи вам кто не велит использовать?



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



С тем же JSON-ом такой лафы (в виде XSD) нет. Однако многие веб сервисы его используют, и ничего как-то живут. Да XSD не панацея, если тебя не информировали вовремя что XSD изменился, и надо использовать новую версию.
А еще есть проблема старых клиентов. Я вообще не представляю как вы у себя можете позволить делать breaking change при наличии 300 филиалов.



Сам Оракл рекомендует разносить по разным базам OLTP и аналитику. Так что достаточно просто их разнести. На OLTP быстрые запросы и много DML, на аналитике длинные запросы и минимум DML-я.




1. При этом ты как-то игнорируешь тот факт, что ошибка приводящая к рассогласованию может с таким же успехом быть и в коде ХП/триггеров.
2. Не надо путать бизнес логику и sanity checks для поддержания целостности. Sanity checks должны в обязательном порядке присутствовать в базе. А логику от туда лучше вынести.




Я про твою конкретную систему вообще не говорил. Я про нее ничего не знаю.

Cross-platform Windows and Mac lifts Delphi sales by 54%

только я лично FM не люблю. Не проще ли было сделать порт VCL? Пока под FM не появятся VirtualTreeView,THTML и др либы подобной сложности, не стоит даже и смотреть в ее сторону, имхо. Сила Д. в сверхпродуктивных, feature-rich и быстрых контролах (что даже на доднете трудно повторить), а не в раскрашенных кнопках.

Но сам факт "поддержки" Mac OSX немного сбивает спесь с евангелистов и ###кодеров, от кривизны рук подавшихся в веб-разработку

А лазарь под вин уже не внушает отвращения, между прочим...

Это сообщение отредактировал(а) AlekXL - 15.2.2012, 23:58

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

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


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


На "как-то" будем ориентироваться? Ну так и на формсах    люди тоже как-то пишут.


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


Узнал новое слово   
У нас интеграция с филиалами не на прямую - через файлобмен. Филиал, в высокой степени автономен. Регламент допускает какое-то время задержки в обмене.  Возможно я тебя ввел в заблуждение, используя слово "интерактивно". Не понмю, что я под ним подразумевал. Вероятно я имел в виду "интенсивно".

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


Так то оно так.. но иногда бывает когда OLTP чуть больше чем OLTP, но далеко не DWH и выносить аналитику в одельную базу, организовывать ETL процессы как то не адекватно накладно. 


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


Еще одно новое слово   
Расчет остатков (запасов) это бизнес логика?
В некоторой степени это системная логика - как бы преаггрегация данных  бизнес-транзакций. Но на основе этих данных принимаются бизнес-значимые решения.
То же самое, скажем, рейтинг прайслистов поставщиков. Тоже своего рода преаггегация. Прайслист - да, как бы бизнесс-объект. А вот рейтинг, уже как бы системный.
Мне не нравится слово бизнес-логика. Я не совсем его понимаю. 

Блин вот серьезно, претит мне идея считать такие вещи как остатки за пределами базы. Очень претит.