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

[metaclass]

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

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

Comments

[plumqqz.livejournal.com]

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

[inv2004.livejournal.com]

А чем не угоден sql. что на нём нельзя написать, что можно на обычном pl/sql например? да, выглядит не очень "бизнес", но зато чистый sql.

В январе на работе крутил мозг, и итоге заменил много pl/sql одним большим закросом, но с большой вложенностью decode, и не очень даже страшно выглядит даже.