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

[metaclass]

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

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

Comments

[metaclass.livejournal.com]

Срач был когда-то, да. Не помню, какую из сторон я тогда защищал, потому что я до сих пор не могу решить, что лучше - бизнес-логика внутри СУБД или дурь с ORM и прочим.
Языки, пригодные для того, чтобы делать бизнес-логику так же эффективно как внутри сервера, не очень массовы.

[zelanton.livejournal.com]

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