![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Бизнес-логика в хранимых процедурах
Я вот думаю: следует ли избавляться от сабжевых процедур, заменяя их на закат солнца вручную в виде кода на обычных языках программирования?
У меня 99% разнообразных отчетов реализовано на Firebird или в виде sql-запросов на пару страниц или в виде selectable хранимых процедур, тоже на пару страниц.
Все бы это хорошо, но деплоймент этого дела огорчает, язык хранимых процедур - более чем полная убогость, т.е. уровня типа "турбо-паскаль интегрированный с sql".
И главное ж, хрен чем заменишь - все остальное закат солнца вручную. В обычном случае - адовы ORM типа Entity Framework и LINQ поверх них. В условно нормальном - руби и ActiveRecord, с метапрограммированием, но у него адаптер к Firebird, по моему, несуществующий. Возможно, питон еще, у него тоже метапрограммирование имеется и kinterbasedb вроде живой.
Т.е. если по хорошему - то нужно что-то вроде LINQ, но чтобы схему БД видел сам, без импорта схемы в 100500 файлов.
PS: не успел дописать: Одна из нездоровых идей - написать транслятор из гуманного DSL с функциональщиной и школьницами с Ph.D. in CS в язык хранимых процедур.
У меня 99% разнообразных отчетов реализовано на Firebird или в виде sql-запросов на пару страниц или в виде selectable хранимых процедур, тоже на пару страниц.
Все бы это хорошо, но деплоймент этого дела огорчает, язык хранимых процедур - более чем полная убогость, т.е. уровня типа "турбо-паскаль интегрированный с sql".
И главное ж, хрен чем заменишь - все остальное закат солнца вручную. В обычном случае - адовы ORM типа Entity Framework и LINQ поверх них. В условно нормальном - руби и ActiveRecord, с метапрограммированием, но у него адаптер к Firebird, по моему, несуществующий. Возможно, питон еще, у него тоже метапрограммирование имеется и kinterbasedb вроде живой.
Т.е. если по хорошему - то нужно что-то вроде LINQ, но чтобы схему БД видел сам, без импорта схемы в 100500 файлов.
PS: не успел дописать: Одна из нездоровых идей - написать транслятор из гуманного DSL с функциональщиной и школьницами с Ph.D. in CS в язык хранимых процедур.
no subject
1. реюзабельные запросы -- это views. (CTE -- это же в пределах одного запроса, не?)
2. для текущей задачи мне нужно минимальное время отклика, а это значит, что логику надо свести до уровня "вызвали хранимку -- получили полный ответ на свой вопрос", поэтому стродания оправданы, будет архитектура, которая не вносит тормозов на этапе "получить от БД что-либо".
3. отдавать всё наружу (в курсорах, например) и обрабатывать client-side -- гарантии лишнего трафика, увеличенного времени отклика и практически гарантия велосипедописательства на тему оптимизации запросов (либо ручное выстраивание планов на каждый сколько-нибудь нетривиальный запрос, что скучно).
4. идея про dsl -- вполне разумная, только сотона в деталях, как обычно. Я бы не смог сдизайнить функциональный dsl, удобный и эффективный для трансляции в plpgsql какой-нибудь.
Да и проверил недавно у постгреса размер стека на рекурсивные вызовы, порядка 1000 для функций, берущих простой int. То есть, компилировать надо во что-то очень императивное.
Ну и конкретно функциональщина там не особо нужна обычно, разве что если поставить цель заменить sql. Но это тоже нехорошо, так как sql весьма таки непростой язык, и есть подозрение, что при обнаружении проблем с эффективностью этих хранимок придётся анализировать сгенерированный код, а то и переписывать его под нужды оптимизатора.
А вот хотя бы нормальная типизация -- уже было бы хорошо.
И ещё вариант, но базоспецифичный: постгрес (и firebird, вроде; и оракл) умеют линковать нативный код, предоставляя ему возможность смотреть в данные, выполнять sql, возвращать результаты. То есть, вполне можно написать библиотеку для любимого языка программирования, которая будет предоставлять хранимые процедуры.
no subject
firebird только с версии 3.0, которая пока еще только в альфе
no subject
no subject
no subject
no subject
1) иметь доступ к текущему подключению
2) иметь доступ к текущей транзакции
3) возможность создавать и выполнять запросы
4) для триггеров иметь доступ к старой/новой версиям записи