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

[metaclass]

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

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

Comments

[stdray.livejournal.com]

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

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

[metaclass.livejournal.com]

А, да-да, точно. Это может, кстати, серьезно спасти мозг.

[sorhed.livejournal.com]

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

[stdray.livejournal.com]

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