Бизнес-логика в хранимых процедурах

[metaclass]

Я вот думаю: следует ли избавляться от сабжевых процедур, заменяя их на закат солнца вручную в виде кода на обычных языках программирования?
У меня 99% разнообразных отчетов реализовано на Firebird или в виде sql-запросов на пару страниц или в виде selectable хранимых процедур, тоже на пару страниц.
Все бы это хорошо, но деплоймент этого дела огорчает, язык хранимых процедур - более чем полная убогость, т.е. уровня типа "турбо-паскаль интегрированный с sql".
И главное ж, хрен чем заменишь - все остальное закат солнца вручную. В обычном случае - адовы ORM типа Entity Framework и LINQ поверх них. В условно нормальном - руби и ActiveRecord, с метапрограммированием, но у него адаптер к Firebird, по моему, несуществующий. Возможно, питон еще, у него тоже метапрограммирование имеется и kinterbasedb вроде живой.
Т.е. если по хорошему - то нужно что-то вроде LINQ, но чтобы схему БД видел сам, без импорта схемы в 100500 файлов.

PS: не успел дописать: Одна из нездоровых идей - написать транслятор из гуманного DSL с функциональщиной и школьницами с Ph.D. in CS в язык хранимых процедур.

Comments

[blackyblack.livejournal.com]

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

[oldmann.livejournal.com]

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

[freedom_of_sea.livejournal.com]

мне тоже не нравятся эти недоязыки

[plumqqz.livejournal.com]

Господи! не в ярости Твоей обличай меня и не во гневе Твоем наказывай меня.
Честно говоря, совершенно не понимаю, почему вариант с данной господом нашим нам в назидание и епитимью рубой выглядит лучше, чем "турбопаскаль с sql".
Нахуа нужен такой же епитимиальный LINQ, когда есть sql (не вообще есть, а вот тут, под рукой, на, бери и пользуйся) - тоже совершенно непонятно.

[zelanton.livejournal.com]

Посмотри например MSSQL Express вместо Firebird. Миграция - дело решаемое, а потом писать скрипты становится много проще.

И помнится когда-то давно у нас был срач я говорил, что сделал так изначально, а ты мне доказывал что так делать нельзя - теряется скорость работа кода сильно нагруженного SQL запросами. Могу правда ошибаться что это был именно ты.

[inv2004.livejournal.com]

Как обычно kx побеждает: база и язык в одном флаконе - делить нет смысла. опердень (но не логика) на java - не неё лёгким движением руки встраивается kx.

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

[stdray.livejournal.com]

>нужно что-то вроде LINQ, но чтобы схему БД видел сам, без импорта схемы в 100500 файлов

В F# 3.0 пилят такие-то Type Providers. Оно сырое, но я смотрел, контексты для Linq2Sql и Entity генерирует на лету.

[fraks-nsk.livejournal.com]

"и kinterbasedb вроде живой".

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

Помечтать можно о другом - что бы SP можно было писАть на нужном тебе ЯП.
Вроде даже были какие-то тесты на этот счет, можно глянуть на то что там в тройке обещают...

[si14.livejournal.com]

Постгря умеет бидон в качестве хранимок.

[altmind.livejournal.com]

надо избавляться от хранимых процедур таких, как они сделаны в РСУБД. У меня есть большая вера в хранимые процедуры, сделаные как в mongodb - на general purpose языке. Ну и вера в CQRS.

[sorhed.livejournal.com]

Бизнес-логику, связанную с перекладыванием данных из одного места в другое и их трансформацию, вполне можно писать на хранимых процедурах. Но ничего кроме (к счастью, в современном энтерпрайзе такого — 95%).

Но и увлекаться не надо, а то получится Oracle Application Express. Или вот я как-то видел написанный на оракловых хранимых процедурах workflow manager, с дёрганием внешних сервисов (на SOAP), проверкой состояния, откатом... вот где ад-то был сотонинский.

[norguhtar.livejournal.com]

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

[tzirechnoy.livejournal.com]

Так Вы и пишыте хранимые на нормальном языке, кто Вам мешает-то?

[alexeyk77.livejournal.com]

Только ХП, ни в коем случае не отдавать БД на прямое растерзание приложению.
Вернее есть случай, когда ХП не очень катят, если это аналитическая прилада, где запросы генерятся на лету, но я так понимаю это не ваш случай.
И еще, лично я воспринимаю SQL как язык манипулирования а не язык программирования. Вот здесь и должен быть водораздел между двумя крайностями "вся логика в ХП" и "вся логика на клиенте".
Да и зачем уходить от более совершенной декларативной пардигмы в каменный век императивного программирования? Неее....

[gds.livejournal.com]

тоже стродаю от подобного дела. Тем не менее,
1. реюзабельные запросы -- это views. (CTE -- это же в пределах одного запроса, не?)
2. для текущей задачи мне нужно минимальное время отклика, а это значит, что логику надо свести до уровня "вызвали хранимку -- получили полный ответ на свой вопрос", поэтому стродания оправданы, будет архитектура, которая не вносит тормозов на этапе "получить от БД что-либо".
3. отдавать всё наружу (в курсорах, например) и обрабатывать client-side -- гарантии лишнего трафика, увеличенного времени отклика и практически гарантия велосипедописательства на тему оптимизации запросов (либо ручное выстраивание планов на каждый сколько-нибудь нетривиальный запрос, что скучно).
4. идея про dsl -- вполне разумная, только сотона в деталях, как обычно. Я бы не смог сдизайнить функциональный dsl, удобный и эффективный для трансляции в plpgsql какой-нибудь.
Да и проверил недавно у постгреса размер стека на рекурсивные вызовы, порядка 1000 для функций, берущих простой int. То есть, компилировать надо во что-то очень императивное.
Ну и конкретно функциональщина там не особо нужна обычно, разве что если поставить цель заменить sql. Но это тоже нехорошо, так как sql весьма таки непростой язык, и есть подозрение, что при обнаружении проблем с эффективностью этих хранимок придётся анализировать сгенерированный код, а то и переписывать его под нужды оптимизатора.
А вот хотя бы нормальная типизация -- уже было бы хорошо.

И ещё вариант, но базоспецифичный: постгрес (и firebird, вроде; и оракл) умеют линковать нативный код, предоставляя ему возможность смотреть в данные, выполнять sql, возвращать результаты. То есть, вполне можно написать библиотеку для любимого языка программирования, которая будет предоставлять хранимые процедуры.

[http://users.livejournal.com/_slw/]

[sergiej.livejournal.com]

ИМХО
1) в ХП имеет смысл хранить только магастабильную логику. То есть такую которую не только не надо менять часто то никому в голову и не прийдёт её поменять
2) если оставляем ХП они должны быть жёстко документированы, и когда это типа "API" вызывает логика приложения повыше это должно выглядеть просто... ну как запрос к базе
3) В ХП стоит оставлять то что там быстрее, всякие аггрегирующие функции, которые на "крутых" языках будут выглядеть красиво но выполняться долго

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

[gds.livejournal.com]

кроме того, очень важно вот что:

[olegy.livejournal.com]

Я для себя году в 2000 решил однозначно, что хранимых процедур в моих проектах не будет. Это после того, как мне несколько месяцев приходилось ездить на объект за 500 км, и в 4 часа ночи (только в это время мне давали 20 минут на остановку работы) менять на сервере код триггеров и процедур.
Сейчас, я, конечно не так однозначно настроен, есть интернет и т.п.
Сейчас мой подход - полностью отделять логику от БД - отдельный модуль, кот. отвечает за связь с базой.
На вопросы "а если мне вдруг нужно будет выполнить какой то SQL запрос" - я отвечаю - "добавляете метод в модуль и в нем делаете в нем любые запросы".
Правда, с отчетами так не получается - отчеты полностью "базозависимы".
Как то так ;-)

[perepertoz.livejournal.com]

чот я так понимаю, с тех пор как я в 10 лет тому назад делал на дельфи отображение и редактирование данных бурения (каждый гок считал своим долгом сделать их в своём формате), с тех пор мало что поменялось :)))

[serbod.livejournal.com]

Я бы выбрал ORM для бизнес-логики и SQL (или надстройку над ним) для отчетов. А ХП пусть ORM создает и пользует по своему усмотрению.