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

[metaclass]

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

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

Comments

[sorhed.livejournal.com]

Жду аки соловей лета. Type providers должны быть везде, ящетаю.

[sorhed.livejournal.com]

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

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

[norguhtar.livejournal.com]

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

[tzirechnoy.livejournal.com]

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

[fas-tm.livejournal.com]

>>описания никто не заставляет НЕ делать. Я вообще все документирую прямо в базе.
Да правда. Пару раз было c большими комментариями. На французском и немецком :)

>>логика снаружи если программ более одной - тоже не особо фонтан.
>>Так в базе поменял - везде поменялось.
И везде все упало :) Тоже бывало :)

[zelanton.livejournal.com]

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

[plumqqz.livejournal.com]

Отсутствие их reuse нормального - не ок.

Что Вы имеете в виду?

Версионирование хранимых процедур и прочая, особенно в Firebird - анус кромешный.

Ну так не имейте дела с файрбердом.

[plumqqz.livejournal.com]

Возьмите DB2 и всласть пишите на коболе, PL/1 или какой-нибудь, прости господи, жабе.
Впрочем, на жаббе можно писать подо что угодно - но этого почему-то никто не любит делать.

[alexeyk77.livejournal.com]

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

[metaclass.livejournal.com]

А, блин, я опять все забыл, reuse уже сделали и я им пользуюсь - Common Table Expressions.

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

[metaclass.livejournal.com]

Императивное сразу в лес. Речь идет о "всунуть функциональщину с метапрограммированием между сервером и клиентом и чтобы за это ничего не было".

[alexeyk77.livejournal.com]

функциональщина это тоже откат вниз, хотя и не в такой низ как все другое. Так что не согласен.
Думаю, имеет смысл обсуждать конкретную проблему/задачу и как ее лучше решить. Многие из отписавшихся идею отказа от ХП не поддержали.
Помимо удобства программирования есть жеи другие факторы:
Безопасность БД. С ХП ее можно обеспечить в сложных оперденях. Далее ее можно так-же и контроллировать. В больших организациях обложенных всякими требованиям по управлению IT/безопасностью это очень важно. Лично я как безопасник запорю любое решение, которое дает с базой работать напрямую.

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

[gds.livejournal.com]

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

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

[stdray.livejournal.com]

Может быть опасно иметь в дело с такой динамичной штукой, по-моему. Сейчас просто стараюсь не трогать руками dbml или edmx, что генерируют десигнеры, при серьезной потребности через partial классы добавляю филды в контекст или в модельки. Изменилась база, потом все развалилось, заставил дезигнер сгененировать все заново и продолжаем работать. Как живется с этими провайдерами пока неясно.

[theiced.livejournal.com]

ребе, извините но вы несёте адову хуйню. портабельность даёт 101%ное избавление от сторед проков (и вообще самописного говносикля).

[theiced.livejournal.com]

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

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

[gsbelarus.livejournal.com]

"постгрес (и firebird, вроде; и оракл) умеют линковать нативный код"

firebird только с версии 3.0, которая пока еще только в альфе

[sergiej.livejournal.com]

+10
с оговорками

[sergiej.livejournal.com]

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

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

[gds.livejournal.com]

а я чётко помню другое, и не поленился проверить. http://www.firebirdsql.org/en/writing-udfs-in-delphi-for-interbase-firebird/ -- это ведь оно и есть.

[gds.livejournal.com]

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

[plumqqz.livejournal.com]

А про нормальных людей это Вы сами видели или, может, рассказал кто?

[inv2004.livejournal.com]

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

[inv2004.livejournal.com]

Да, язык застрял, до для "бизнес" логики самое то. Ничего хитрого, чтобы не влезло в мозг "бизнес"мена.