Pull to refresh
Comments 112
Ниже Вы можете увидеть срач о том, что хранить логику в БД — это ужасно, неудобно, непереносимо, непонятно и т.д.
UFO landed and left these words here
Полюбопытствую — что именно и как хотите снять с моделей Magento и переложить на плечи БД?
UFO landed and left these words here
Да, утечка памяти — это проблема в PHP < 5.3, если остаются циклические ссылки и скрипт исполняется долго. Для ее решения в Magento 1.5 (1.10), которая выйдет в ближайшие пару недель, у моделей появился метод clearInstance(). У продуктов он чистит все циклические ссылки, в результате чего PHP может корректно очистить память.

Конечно, такое скрытое управление памятью в PHP < 5.3 делает сложным работу. Особенно для таких интересных архитектур как Мадженто. Но, радует, что хоть в 5.3 PHP научился уже самостоятельно убирать циклические ссылки.

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

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

Поэтому делайте (так на самом деле многие пользователи Мадженто поступают), но аккуратно. Да и с выходом 1.5 утечки памяти при импорте-экспорте продуктов решены.
UFO landed and left these words here
Порадовало, что целых два человека добавили статью в избранное — не уж то на практике будут применять?:)
В своё время участвовал в одном «энтерпрайз»-проекте (с очень нехилой для учётных систем загрузкой), всю (по-максимуму) логику (в т.ч. CRUD) делали на хранимках в T-SQL. По-моему достаточно логично. Переносимость — не знаю на сколько она важна, реально в жизни не сталкивался с нужностью перехода с одной СУБД на другую. Единственный заметный минус — дублирование логики, валидации например. А производительность и масштабируемость, на сколько я понял из практики, выигрывает. Так что почему бы аналогично с MySQL не попробовать…
Боюсь, у всех с опытом разработки от 5 лет есть подобный опыт, в том числе и у меня. Действительно порой оправданно с точки зрения производительности.
Кроме производительности бывает еще и потребность атомарности в ситуациях вида SELECT + расчёт-на-клиенте + UPDATE/INSERT. Лочить таблицы — херить производительность, а транзакции не спасут из-за неоткатываемости клиентского пересчёта. Вот тогда и выручают stored proc и триггеры.
Забыл уточнить, что при этом вне хранимок не было ни строчки SQL-кода (работа с БД происходила исключительно через обращение к хранимым процедурам). Думается мне что это очень неплохо с точки зрения защиты от SQL-иньекций и ошибок строковой логики.
Поделитесь чем профилировали процедуры и делали отладку?
Вы будете смеяться, но таки ничем. Исключительно вручную и на глаз. Если бы знать для этого какие-то удобные инструменты, сэкономили бы уйму времени. Может Вы можете что-то порекомендовать? Сейчас говорят уже вроде в Visual Studio 2010 что-то такое появилось.
(SQL Management Studio / VS) < 2005
SQL Profiler, SQL Plan Analizer, ну и есть разные продукты от Red Gate
На вопрос «где надо хранить логику данных?» может ответить здравый смысл. Им можно пользоваться не опасаясь, что это «не лучший подход».
Ребята, а чего вы все такие серьезные? Это топик just-for-fun. Просто мне захотелось проверить, можно ли так сделать. А вы тут действительно развернули холивар на тему «так делать низзя».
Минус который я вижу — непереносимость кода.
Приложение привязано в конкретной БД, либо повышается стоимость разработки.
UFO landed and left these words here
>то вы пишите запросы по второму разу и вы не сможете дать гарантию того, что бизнес логика работы БД не нарушена.

Во-первых, что значит «бизнес логика работы БД не нарушена». Если хранимок нет — нет и бизнес логики в БД.

Во-вторых, для персистентных состояний (если они нужны) существуют транзакции.
Дорогой друг! Есть прямо противоположная ситуация. Вы, видимо, никогда не меняли свою БД. Представьте ситуацию, когда стоит задача сменить СУБД (смена предпочтений клиента, смена главного архитектора, пожелания «директора», да мало ли ситуаций). В своём случае я использую ORM и модели использующие этот самый ORM. Дык вот я просто сменю бекэнд в ORM-е и продолжу работать как ни в чем не бывало. А что сделаете вы? А если ранее ваши «хранимки» были заточены под Oracle, а теперь нужен MS SQL? А если нужно поддерживать несколько СУБД? А если среди них будет СУБД без «хранимок», а заказчик хочет всенепременно?

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

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

орм конечно круто и модный тренд, но далеко не панацея и накладывает свои ограничения.

и даже с орм миграция с одной базы на другую, даже SQL -> SQL, всегда заканчивается полным геморроем (если конечно проект не в 3 строчки и 2 формочки). Это еще тот вопрос что проще смигрировать хранимки или поменять орм адаптер.
Был опыт перевода довольно крупного проекта с MS SQL на MySQL. До этого в качестве ORM был Linq2Sql. Купил devart dotConnect, поменял в одном месте дата контекст и коннекшн стринг и всё заработало. Опен-сорс варианты, увы, работали хуже.

А вот для отчётов был другой фронтенд, и там юзались хранимки. А в мускуле синтаксис другой, пришлось попотеть. И, на удивление, жирные запросы работали намноооого медленне MS SQL.
>И, на удивление, жирные запросы работали намноооого медленне MS SQL.
А что, собственно, удивительного? MS SQL, как ни крути, а гораздо более продуманная и производительная СУБД чем MySQL. Ну, может быть последние фишки с HandlerSocket позволяют говорить что MySQL производительнее MS SQL _в отдельных случаях_. Но в целом мускулю и по производительности и по удобству до МСа еще расти и расти.
UFO landed and left these words here
А давайте «по-менеджерскому» или «аналитически»? Я не конкретизировал языки, а в разных языках ORM-ы некисло отличаются по возможностям и производительности. Я к тому, что оценки разные.

Собственно, давайте оценивать затраты. Что именно переписывать для новой субд? Я вот экспериментировал с тремя, начал с mysql, потом postrgre и ради интереса mssql. Собственно, переписывание заключалось в создании вьюшек и процедур для mssql, и то для эксперимента. В целом же вся система отработала отлично. Но с точки зрения аналитики, затраты на переписывание+отладку всех полностью процедур под новую СУБД сравнимы с затратами на корректировку высокоуровневой модели?

А остальное вполне себе реальность на мелко-средних проектах, но никак не раздувание. Были моменты, когда у заказчика менялись предпочтения, были моменты смены философии у начальства/проектировщиков, по всякому. Но мы же хотим аналитически? Давайте оценим все ситуцации. Для простоты их две. Смена языка: тут вопрос в поддержке нужных функциональностей в ORM-е в нужном языке. Чаще всего базовый функционал таблицы+связи есть везде, вопрос в производительности. Второй момент в смене СУБД. Если уж мы оцениваем аналитически, то в целом ответ очевиден.

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

Что мне не понравилось выше, так это категоричность, типа «мой мнение завсегда верно». Именно против этого я и выступал в форме равного противоречия.
UFO landed and left these words here
Ну вообще-то можно использовать и хранимки, и ORM. То есть какую-то специфическую и жутко тормозную выборку засунуть в процедуру, а в ORM дергать метод, который будет это всё возвращать уже в объектах.
UFO landed and left these words here
Когда нужно было сделать третьего клиента к БД, то создал веб-сервис, который работал с БД, а клиенты обращались только к нему :)
Вива! Наконец-то, хоть кто-то вспомнил про трёхуровневую архитектуру! )
Это когда производительностью можно в допустимой степени пренебречь. Когда все супер-пупер-критично, то написание процедур оказаться выгоднее (в плане трудозатрат) написания модулей на С-ях.
Но все равно пятерку за паттерн Интерфейс вы получаете )
Можно было, хотя сервис был на сях — ничего другого просто не знал практически. А про паттерны тогда и не слышал, преподавали нам процедурное программирование как верх достижения человеческой мысли :)
надо разделять приложение на три части — данные, UI и так называемая «бизнесс-логика».
Эту «бизнесс-логику» реализуем на том же самом php в отдельных классах. И, когда нам понадобятся клиенты на C#, публикуем эти класс в виде (к примеру) web-сервиса и работам только с ними.
Получаем тоже самое, только вместо ХП — методы сервиса.
Если думать об этом заранее, то можно написать приложение так, чтобы создание API занимало минут 5.
Не могу сказать как в ZF, а в Rails используя RESTful routes можно уже облегчить себе жизнь, и данные запрашивать в XML/JSON/… Для простых случаев этого более чем достаточно.

XML-RPC/SOAP/… также никто не отменял для более тяжелых случаев.
Поверьте пользовался, но это был большой корпоративный интранет проект java + oracle.
О другой БД речи не шло.

В webdev все несколько иначе. Есть проект php/perl/ruby/python + mysql. В некоторый момент при превышении нагрузки необходимо перейти на тот же postgresql.
Вот тут action record решения и являются наиболее гибкими.
Пробовал когда-то (не для веба) — отпугнуло неудобство разработки хранимок и ограниченный функционал (сейчас может поменялось, но тогда не нашёл способа динамически менять имя таблицы в запросе).
Ещё подкину пару минусов хранения большей часть логики в БД:
1. базу обычно стараются разгрузить, потому что добавить ещё ноду с базой на порядок сложнее, чем ноду с веб-аппликейшном
2. работа в команде с базой таки почти не прёт
3. очень трудным становится сделать так, чтобы одна нода продакшена работала на новой версии логики какое-то время (чтобы проверить её)
1. Правильно написанные хранимые процедуры способны разгрузить базу (не забываем про навороченный оптимизатор SQL-запросов в любой субд)
2. Да, но сколько ж вы туда собираетесь загнать кода, что вам нужна команда DBA?
3. Проверять логику на продакшене? Хм…

Есть у такого подхода один убойный плюс, про который все почему-то забыли. Это безопасность. Можно закрыть доступ к обычным селектам-апдейтам и делать все через хранимые процедуры. Если мальчиш-плохиш вдруг сопрет пароль от базы, не зная процедур — он не сможет сделать ничего. И в любом случае не сможет слить базу.
Это почти стандарт при разработке например банковских систем.
Я написал — бОльшую часть логики. Понятно, что надо знать меру и в том, и в другом подходе. Всё выносить из базы в код тоже нельзя (я тоже против этого), но и морфологичеикий анализ в базе делать — это извращение. Я вот о чём хотел сказать.
1.А неправильно написанные способны ложить базу
2.Базу действительно лучше писать одному ИМХО.

Хранимые процедуры имеют мало общего с бизнес-логикой. С нормальной бизнес-логикой. Разумеется почти всё можно сделать на SP и T-SQL но это такой тупиковый геморой. Особенно быстро это становится понятным при работе с несколькими базами, при репликациях и т д.

А безопасность да.
1. Не аргумент — для этого есть тестирование.
2. На примере Oracle — действительно крупную задачу удобно разбить на части и реализовывать в разных пакетах (например) разными разработчиками. И да, есть варианты реализации в БД вышеупомянутых «крупных задач».

В остальном да, идея не новая, спорная, но… вариант :)
Если мальчиш-плохиш вдруг сопрет пароль от базы, не зная процедур — он не сможет сделать ничего. И в любом случае не сможет слить базу.

Что ему помешает вызывать процедуры? Через процедуры слить нужную инфу? Чучка больше времени?
Это почти стандарт при разработке например банковских систем.

нема такого стандарта, не почти, никак.
Эээ, что, простите? У вас нема такого стандарта? Э…
Вот представьте себе таблицу «юзеры». Пароль SQL-суперадмина от «боевой» бд есть только у сурового начальника службы безопасности. Заводить и редактировать юзеров может только он (ну ок, «мальчик» от его имени).
У обычных клиентов (читай программистов банковского приложения) есть только очень усеченная в правах учетная запись. Без права выполнять селекты, инсерты или апдейты на таблице юзеров. Есть только доступ к одной хранимой процедуре, которая по паре параметров (логин, хэш пароля) либо возвращает 1 строку с профилем текущего пользователя, либо — если логин или хэш пароля не верны — возвращает ноль строк.
Ну вперед, слейте в таком конфиге таблицу «юзеры». Или хотя бы пары «логин — хэш пароля».
У нас есть довольно крупный проект, написанный на MSSQL/.Net/XSLT в котором используется как раз такой подход. Вообще да, это работает, но у подхода довольно много недостатков, например сложнее горизонтально масштабировать, ошибки в коде хранимок часто невозможно отследить в силу того, что код не компилируется, я уже молчу про юнит-тесты для этого добра.
П.С. Тому проекту скоро уже лет 7, поэтому поменять что-либо уже не представляется возможным, но если бы я сейчас стартовал аналогичный — ни за что бы не выбрал подобную модель.
Проблемы, описанные Вами, существуют для более ранних технологий MS.
1. Сейчас есть возможность писать хранимки на c#. Соответственно, Вы можете в них прописывать соединение к внешнему SQL серверу. И, таким образом, производить горизонтальное масштабирование. Попутно к этому можно много на дублирующем сервере привязать.

2. Сейчас хранимки пошагово отлаживаются. В т.ч. на tsql.

Попробуйте MS SQL 2008 + Visual Studio 2010. Проект типа database и вперёд. Это неимоверное удовольствие.
Я про все это прекрасно знаю.
1. Да, мы это даже используем в одном из наших приложений. Небольшие куски кода вполне возможно разворачивать на сервере с БД и динамически переносить на внешние сервера, но чесно говоря, по моему мнению это уже как бы и не хранимки. Плюс, если вы например попытаетесь сделать какое-нибуть кеширование данных в памяти с помощью статических полей или просто распаралелить какой-нибуть алгоритм, который должен обращатся к синхронизированным данным, то это выльется в головную боль при разворачивании, в связи с тем, что это требует UNSAFE-прав от пользователя, а это сложно и часто пугает заказчиков.
2. Знаю. Помогает не сильно.
Да-да, но удовольствием это перестает быть когда у вас в проекте полтора миллиона строк кода и десятки компаний-заказчиков с тысячами пользователей.
Все зависит от задач и масштабов. Подход прекрасно работает с мелкими проектами и малой загрузкой. Но когда масштабы растут, архитектура тоже должна менятся.
Ну я в принципе предполагал, что увлечённый человек это попробовал. =)

Тогда, если не возражаете, я хотел бы Вас немного помучить.
1. Если сравнить 2-х звенку с логикой в БД и 3-хзвенку (web не рассматриваем, т.к. другие случаи). То неужто (по Вашему мнению) геморней писать логику в БД, чем пилить трёхзвенку? Тут же и частей больше, и удобства при программировании меньше и т.д.
2. А вообще апдейты и поддержка клиентов при логике в БД насколько проблемны? Потому что код поменять — это dll переподключить новую. Но если ещё структура меняется, да если ещё пользователи работают. По горячему (когда пользователи работают) вообще это возможно делать?
3. Коллективная разработка в случае логики в БД насколько проблемна? Какие основные проблемы?

Спасибо.
1. В случае с 2-х звенкой у вас в БД просто неявно будет спрятано два уровня — логики и доступа к данным. В противном случае очень сложно, а то и вовсе невозможно будет организовать юнит-тесты бизнес-логики, а без них жить очень сложно. Соответственно, в общем случае нет никакой разницы, где находится логика — на сервере БД или на middle-tier сервере, а так как последний проще масштабируется, то выбор очевиден. Конечно, если приложение небольшое и развивать его не планируют, то 2-х звенка банально дешевле, поэтому стоит выбирать ее. В таком случае 3-х звенка это как использовать паттерн MVC для домашней странички с фотографией кота — профита никакого, а затраты непропорционально огромны, лучше написать простейший скрипт на РНР. Но если ваш проект куда больших масштабов то нужны другие подходы.

2. Приложение с логикой в БД у нас браузерное. Построено на паттерне MVP, где модель как раз большей частью и лежит в БД, а остальные части в виде XML/XSLT на веб-сервере. Поэтому как апдейтить клиенты в таком случае я и сам не знаю. Другое приложение, в котором есть клиенты, работает через middle-tier, который как раз и обеспечивает изоляцию структуры БД от клиента.
Что касается апдейта структуры БД и логики на лету — то это очень сложно. У нас специфика позволяет это делать например ночью, когда приложением не пользуются, поэтому мы особо не заморачиваемся. Но вообще, процесс у нас обычно занимает считанные минуты, так что иногда это возможно сделать и на ходу, просто временно заблокировав сервер (клиенты умеют работать в оффлайне).

3. Каждое изменение структуры таблиц в БД оформляется в виде отдельного скрипта с именем вида 20110205.000.vasya.pupkin.sql и кладется в специальную папку в репозитории. Плюс есть специальный инструмент, который позволяет отслеживать изменения в процедурах и других обьектах основной девелоперской БД и раз в пол часа коммитит их в репозиторий. При обновлении сначала сносятся все процедуры и прочие обьекты кроме таблиц, потом проганяются скрипты, которые еще не применялись к этой БД, в нужном порядке, после чего пересоздаются все процедуры с нуля. Все автоматизированно. Единственный минус — не видно кто из разработчиков что менял в процедурах и для чего, так как скрипт все комитит от одного аккаунта и с одним комментарием «автоматический коммит». Процес довольно сложный и не совсем удобен, но отточен за годы разработки и сейчас его менять никто уже не будет.

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

Тот кто не работал с SQL — системами у которых бизнес — логика размещена на сервере, даже не представляют насколько это ОБАЛДЕННАЯ вещь!
2 сек. и все работают по новым правилам!

Естественно что ресурс SQL — Server (это проблема кластера..) пожирается с огромной скоростью (но это зависит уже от реализации), но с точки зрения поддержки бизнес-систем это еще раз ОБАЛДЕННЫЕ условия работы!

Не нужно так строго и однозначно говорить «бизнес-логика на SQL» — это плохо…

Видел я «популярные» бизнес-системы, в которых на производстве пользователей выбивали из сессий по графику…

Для работы в WEB — оценить не могу… слаб я в этом вопросе.

Добавлю:
нужно очень хорошо заранее продумать и построить систему.
Но это действительно сложно. :(
и не на уровне ЦПШ это делается

:) ЦПШ — это не Центральная Партийная школа КПСС
а Церковно — приходская школа…
это приходит потом… в зависимости от понимания МИРОВЫХ ТЕНДЕНЦИЙ РАЗВИТИЯ

Sorry… если кого — то обидел.
Где-то встречался с аргументом в пользу такого подхода применительно к Oracle: сколько веб-технологий сменилось за время существования PL/SQL? Да он существовал все то время, что вообще существует веб. Технологии постоянно меняются, а PL/SQL лишь расширяется и весь старый код более-менее работает. Люди городят хитрые абстракции для доступа к БД на случай ее смены, но гораздо чаще меняется не БД, а сама веб-технология.

На самом деле хранить логику в базе довольно удобно (по крайней мере в случае с Oracle). То что делается на middle tier достаточно объемным кодом, на PL/SQL зачастую делается парой строк, а работает быстрее и надежнее, ведь данные не нужно никуда гонять и с транзакциями проще.

Проблемы действительно начинаются на больших проектах из-за сложностей с управлением версиями, тестированием и, конечно, масштабированием. Но для небольших проектов хранить логику в хорошей СУБД — это незаслуженно непопулярный подход. Вполне можно им пользоваться.
небольшие проекты не в состоянии пользоваться дарами Oracle (не по карману точнее), это удел больших интерпрайзов.
Есть такое дело, но я подозреваю что в других СУБД с этим сейчас уже тоже получше стало. Просто не писал под них в этом стиле, поэтому делюсь тем, с чем работал.
А кроме Oracle других SQL — нет?

MS SQL Express разных версий…
сейчас там ограничения вполне достойные…
даже для реальной жизни их хватает… И ресурсы не очень большие…
когда проект один — вполне торт

а если вы захотите захостить несколько небольших проектов на одной машине (вполне естественное желание) — то сразу же не торт
UFO landed and left these words here
И он замечательно отлаживается пошагово в IBExpert, например.
Я всецело поддерживаю FB, но пошаговая отладка процедур в IBE — это миф. Сам FB такую фичу не поддерживает, а то что есть в IBE — это эмуляция, и она не всегда работает так как надо. Эта тема с завидной регулярностью поднимается на sql.ru
Почему миф, если работает? Пошаговая отладка вообще мало где работает, как надо. Меня то, что делает IBE, устраивало на 100%.
Но в любом случае, спасибо за инфу. Даже не догадывался, что это эмуляция.
UFO landed and left these words here
Но писать большие куски кода на PL/SQL — это сильная боль в седалище… Наверное, это вопрос компромиссов…
Скорее вопрос привычки. Сам PL/SQL не так уж и плох. Та же интеграция SQL'а очень удобна. Но да, он отличается от того на чем обычно программируют сегодня и требует определенной перестройки. Например почти полного отказа от ООП, ибо там с ним плохо, да и не удобна работа с данными в ООП без ORM. Но если подумать, то в бизнес-задачах возможности ООП вообще мало где используются сегодня. В основном классы являются просто структурными единицами, с чем вполне могут справиться и пакеты. Есть конечно любители rich-моделей (я и сам в их числе), но это не мейнстрим. Практически любой современный фреймвок вынуждает отказаться от развитого объектного проектирования и остановиться на какой-то не совсем логичной и совсем не компактной, но зато стандартной структуре.

В общем, если не относится к PL/SQL как к злу, а воспринять это как возможность поработать в другом стиле, то он не особо раздражает. Раздражает только отсутствие человечных IDE. При всей строгости PL/SQL'я IDE могла бы делать там очень много всего, но не делает или делает не удобно.
А как же стандартные IDE для оракла — TOAD, SQL Navigator, PL/SQL developer и SQL Developer?

Там даже дебаггинг есть, и SVN прикручен к SQL Developer.
Не удобные и туговатые они по сравнению с хорошими IDE для Java, например.
Есть такое, особенно оракловый SQL Developer. А вот PL/SQL developer достаточно шустрый, что особенно в нем нравится — автоматическое создание новых коннектов к базе для нового окна. Не нравится — не может делать одновременных коннектов к разным базам.

Перед Java-вскими IDE не стоит задачи отображения результатов запроса, а он может быть очень большим и отжирать много памяти.
На самом деле в любой приличной Java IDE штатно или через плагины можно выполнять запросы и смотреть результаты. Естественно, это далеко не основная фича, поэтому она обычно реализована довольно примитивно.

Но в целом дело вряд ли в памяти, потому что у тех же Java IDE, например, создается и поддерживается гигантский индекс для code completition по всем пакетам, классам, методам, полям, переменным, xml'кам etc. Причем он строится и по коду который пишется вот прямо сейчас и может быть вообще не валидным. Разработчики всех этих IDE потратили уже столько сил на эту фичу, что она реально работает настолько круто и удобно, что писать без нее или с каким-то примитивным комплетишеном вроде того, что можно встретить в каком-нибудь TOAD'е, как-то не комфортно.

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

Я не думаю что редакторы PL/SQL или другого языка хранимых процедур когда-нибудь дойдут до чего-то подобного — просто слишком маленький рынок. Как и для Scala, к примеру, которая мне очень нравится, но писать на ней я не могу, ибо при всей ее выразительности на Java выходит быстрее. Потому что для нее есть хорошие IDE, а для Scala пока только ущербные плагины к ним.
Согласен с вами. Спасибо за комментарий, с Java IDE дел не имел, было полезно узнать.
Одно уточнение — отладка есть не в IDE, а в самом Oracle (DBMS_DEBUG). В IDE просто интерфейс к нему.
Не знаю, может я такой привередливый, но мне много всего не хватает в PL/SQL. Не хватает элементарных структур данных (нормальных, а не прикоцаных коллекций), не хватает механизмов манипуляции этими данными.

А некоторые «приёмы» заставляют меня вспомнить о залихватском сишно-ассемблерном детстве:

declare
  x s_t := s_t('C', 'A', 'B');
begin
  for s in (select column_value from (table (x)) 
                 order by column_value)
  loop
    dbms_output.put_line(s.column_value);
  end loop;
end;


Для тех, кто не в теме — это сортировка коллекции PL/SQL-style :)
Думаю, в любом языке найдется что-то, от чего хочется биться головой об стену. Мир не идеален, вместе с PL/SQL :)
Интересны похожие статьи про разработку на Python&Postgres (для использования на практике). С MySQL такого делать не хочется…
Для одного проекта, делал похожую реализацию для бэкенда, но и то — использовал Postgres.
Возможно, что для некоторых задач — такой подход оптимален.
Но в большинстве случаев — проще использовать более привычные/традиционные технологии. Особенно, когда в разработке/поддержке принимают участие несколько человек.
У нас на Oracle пара совсем не маленьких проектов так и сделаны.
Очень удобно — клиенты на Java, Delphi и Web. Отладка по шагам присутствует.
Всем нравится, все довольны.
Но не буду утверждать, что так надо делать всегда.
Какая у Вас версия Oracle? У нас до 10.2.1.5 (дай бог памяти, вроде так) дебаггер PL/SQL мерзенько вис по любому поводу…
На самом деле не ново. Работал в компании. Там все было подвешено на Oracle. Как факт она была необходима. Так вот для вывода всей аналитики, статистики и т.д. был разработан похожий фреймворк. Он даже код генерировал сам. Не MVC конечно. Но использовать было на самом деле удобно. Учитывая, что разработка и логики и интерфейса была на одном языке. Это конечно не супербонус, но затея имеет право на жизнь.
Я и не говорил, что это ново. Я ссылаюсь в тексте статьи на проект, в котором был применен подобный подход еще в 2006 году. Тогда у меня и родилась идея опробовать данный подход на MySQL с его несравненно более обрезанными возможностями по реализации хранимых процедур. Просто руки до этого дошли только сейчас.
Делал как-то с товарищем один модуль к проекту. Так вот там такой подход (перенос логики в БД) оказался выгодным — он быстрее работал.
за счет того, что встроенные процедуры не требуют постоянно соединяться, аутентифицироваться итд. они работают с правами самой базы.
О фактическом исполнении описанном в топике — я не говорю, возможно это для кого — то толчёк.

Речь идет о самой идее «Логика — это проблема сервера» ????

Ответ в комментариях стартера «Ребята, а чего вы все такие серьезные? Это топик just-for-fun.»
извините… отстой. А зачем тогда поднимать тему?

Я принимаю тему как вопрос «Есть ли жизнь на Марсе ?»

Мой ответ: Да, есть.
Вопрос ее реализации.

Если вы планируете построить долгоживущую и позволяющую дальше развиваться
систему — то у вас при использовании логики на серверной стороне — ЕСТЬ ПЕРСПЕКТИВЫ
железо развивается намного быстрее ПО ( пока ), есть много разных способов…

Если вы хотите всю логику своей системы положить на клиента — да у вас есть фора… несколько месяцев
(или небольшое количество лет)

В идеале ( утрирую естественно… )
у меня есть телефон!
я все свои обязанности по могу выполнить через него!
( к грузчикам это не относится )

Мы говорим о том, что ИТ может дать менеджерам, независимо то того какого уровня эти менеджеры.
а по жизни… мы на них работаем ( нагружаем «лишними» галочками конечного пользователя, чтобы потом дать манаГерам красивые отчеты, которые они нам готовы оплачивать… и т. д.

и в конце концов ( некоторые) — дают понять что кто-то или что-то мешает данной компании.
Это идеал…

а на самом деле и сейчас и всегда — информация -это повод для размышления.
Мы со своей стороны даем информацию для принятия решения…
ааааааааааааааааА на ТОЙ стороне сидит ДЕБ*Л
и что вы можете сделать?

Не переоценивайте свои возможности.

ИТ, по сути — всегда на тонну стали ( молока, сала, или молока )

Однако сия замечательная функция не работает применительно к MySQL. Потому...

надо было оставить MySQL. Не для этого она.

PS
данный подход имеет место для систем со сложной БД и логикой, особенно когда с БД работает более одного приложения. в данном случае, наличие единого согласованного api на уровне субд это плюс.
В книжках по СУБД и БД написано на первой странице — база должна быть настолько простой насколько это возможно.
На личном опыте убедился что перенос бизнес-логики в базу это зло. Такой подход возможен но он учит ездить задом наперёд. Это не верно даже с точки зрения хороших манер.

Вопрос — кто-нибудь реально сталкивался с необходимостю смены платформы или базы данных? Удалось ли это сделат «щёлкнув пальцами» даже при наличие всех грамотных слоёв приложения и отряда хранимых процедур в базе?

За несколько лет веб-разработки сталкивался всего однажды, совсем недавно. Проект на python (Django) переезжал на моих плечах с PostgreSQL на MySQL. ORM справился со всеми запросами, кроме одного — была какая-то выборка наискосок по всей базе данных, которая причудливо сломалась.
Ну сравнительно приличный, социальная сеть для веб-мастеров со всякими сопутствующими плюшками, и биллинг.
Есть два момента. Смотря для чего, как говорится. Для высоконагруженных систем никто не решится это делать, в частности большинство грандов вообще ушли к NoSQL базам, я логика-то вся ясное дело в коде. А вот для «обычных» приложений вполне можно. Всё зависит от ситуации, не нужно просто критично подходить. В статье описан просто способ, не более того. Жаль, без сопроводительных советов «где применять, а где нет». Самое главное, что у всего (вообще всего) есть плюсы и минусы.

Ответ на ваш вопрос: сталкиваются люди и регулярно. И, по уму, такое столкновение должно быть заложено в любой проект помноженное на вероятность/риск.
То что «люди сталкиваются» это понятно по кругам на воде. Но я лично не встречал людей которые в здравом уме и ясной памяти «портируют» живую базу с одной СУБД на другую.
Ещё понятно если десяток таблиц. Но если это реальный монстр стянутый отношениями как паутина плюс сотен пять процедур… Мне кажется это выдавание желаемого за действительное. Всё равно прийдётся вручную всё проверять. Это если какая-нибудь база данных сайта. А если банка? Или железнодорожного узла управления.

Я бы не рискнул писать серъёзное приложение которое предполагало бы смену платформ или СУБД.
Никто не горит особенным желанием мигрировать с одной СУБД на другую, это уж точно.
При таком подходе что будет со скоростью отработки скриптов? Вы делали какие-либо бенчмарки?
Насколько мне известно использвание хранимых процедур в MySQL несколько негативно сказывается на производительности системы, чем если бы использовались простые select-ы, insert-ы и т.п.
Дети, не делайте так. Работать будет и вы даже сможете написать работающее приложение. Но вы потратите время на изучение тупикового пути.
Делайте как написано в книжках — простая база, слой видов и хранимых процедур в базе, слой доступа к данным в приложении, слой бизнес-логики в приложении, слой отображения.

Эти правила как и правила дорожного движения написаны кровью!
Биллинговые системы у Опсосов, крутящиеся на Оракле, всю логику имеют в базе — куча пакетов, процедур и функций, зачастую заврапленные с непонятными наименованиями вида kk_576_ml и т.д. Сотни пакетов и продур, тысячи таблиц, миллионы строк кода.

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

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

Второй проект — небольшое веб-приложение. Вся логика — в БД (для сравнения, кода на Джаве — 50к строк, кода на PL/SQL — 25к). Из очевидных минусов — геморройность при отладке, завязка на одного человека (DBA).
Те, кто вопит о том, что логика в БД — зло просто никогда не делал проектов со сложной логикой. Логика в БД удобна в первую очередь тем, что абсолютно не привязана к клиенту.
Трехзвенная архитектура, а не клиент-сервер позволяет решить проблему разных клиентов.
А меня больше всего заинтересовало, как вы сделали инициализацию приложения Zend Framework из командной строки — расскажите?
Only those users with full accounts are able to leave comments. Log in, please.