Бизнес-логика в хранимых процедурах
Feb. 10th, 2012 08:28 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
metaclassЯ вот думаю: следует ли избавляться от сабжевых процедур, заменяя их на закат солнца вручную в виде кода на обычных языках программирования?
У меня 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 в язык хранимых процедур.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2012-02-10 06:09 am (UTC)no subject
Date: 2012-02-10 06:13 am (UTC)no subject
Date: 2012-02-10 06:25 am (UTC)(no subject)
From:no subject
Date: 2012-02-10 06:28 am (UTC)no subject
Date: 2012-02-10 06:28 am (UTC)no subject
Date: 2012-02-10 06:43 am (UTC)Как там в ораклах с отладкой ХП?
(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2012-02-10 06:24 am (UTC)no subject
Date: 2012-02-10 07:10 am (UTC)Честно говоря, совершенно не понимаю, почему вариант с данной господом нашим нам в назидание и епитимью рубой выглядит лучше, чем "турбопаскаль с sql".
Нахуа нужен такой же епитимиальный LINQ, когда есть sql (не вообще есть, а вот тут, под рукой, на, бери и пользуйся) - тоже совершенно непонятно.
no subject
Date: 2012-02-10 07:40 am (UTC)(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2012-02-10 07:13 am (UTC)И помнится когда-то давно у нас был срач я говорил, что сделал так изначально, а ты мне доказывал что так делать нельзя - теряется скорость работа кода сильно нагруженного SQL запросами. Могу правда ошибаться что это был именно ты.
no subject
Date: 2012-02-10 09:07 am (UTC)Языки, пригодные для того, чтобы делать бизнес-логику так же эффективно как внутри сервера, не очень массовы.
(no subject)
From:no subject
Date: 2012-02-10 07:32 am (UTC)Ну а в целом я за хранимые: меньше всяких ненужных взаимодействий и сущностей и, в итоге, поддерживать и отлаживать проще.
no subject
Date: 2012-02-10 09:19 am (UTC)(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2012-02-10 08:09 am (UTC)В F# 3.0 пилят такие-то Type Providers. Оно сырое, но я смотрел, контексты для Linq2Sql и Entity генерирует на лету.
no subject
Date: 2012-02-10 09:07 am (UTC)(no subject)
From:(no subject)
From:no subject
Date: 2012-02-10 09:02 am (UTC)На сколько я понял - не то что бы живой а просто еще не до конца умер.
А вот его автор - как раз вроде умер, а нового не появилось.
Оно вроде пока поддерживает последние версии FB, но вот последнюю версию самого питона - вроде как уже не поддерживает.
И это печально.
Помечтать можно о другом - что бы SP можно было писАть на нужном тебе ЯП.
Вроде даже были какие-то тесты на этот счет, можно глянуть на то что там в тройке обещают...
no subject
Date: 2012-02-10 09:20 am (UTC)no subject
Date: 2012-02-10 09:56 am (UTC)no subject
Date: 2012-02-10 10:51 am (UTC)Впрочем, на жаббе можно писать подо что угодно - но этого почему-то никто не любит делать.
(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2012-02-10 10:20 am (UTC)Но и увлекаться не надо, а то получится Oracle Application Express. Или вот я как-то видел написанный на оракловых хранимых процедурах workflow manager, с дёрганием внешних сервисов (на SOAP), проверкой состояния, откатом... вот где ад-то был сотонинский.
no subject
Date: 2012-02-10 10:27 am (UTC)no subject
Date: 2012-02-10 10:32 am (UTC)no subject
Date: 2012-02-11 04:34 pm (UTC)no subject
Date: 2012-02-10 10:59 am (UTC)Вернее есть случай, когда ХП не очень катят, если это аналитическая прилада, где запросы генерятся на лету, но я так понимаю это не ваш случай.
И еще, лично я воспринимаю SQL как язык манипулирования а не язык программирования. Вот здесь и должен быть водораздел между двумя крайностями "вся логика в ХП" и "вся логика на клиенте".
Да и зачем уходить от более совершенной декларативной пардигмы в каменный век императивного программирования? Неее....
no subject
Date: 2012-02-10 11:12 am (UTC)(no subject)
From:no subject
Date: 2012-02-10 12:01 pm (UTC)1. реюзабельные запросы -- это views. (CTE -- это же в пределах одного запроса, не?)
2. для текущей задачи мне нужно минимальное время отклика, а это значит, что логику надо свести до уровня "вызвали хранимку -- получили полный ответ на свой вопрос", поэтому стродания оправданы, будет архитектура, которая не вносит тормозов на этапе "получить от БД что-либо".
3. отдавать всё наружу (в курсорах, например) и обрабатывать client-side -- гарантии лишнего трафика, увеличенного времени отклика и практически гарантия велосипедописательства на тему оптимизации запросов (либо ручное выстраивание планов на каждый сколько-нибудь нетривиальный запрос, что скучно).
4. идея про dsl -- вполне разумная, только сотона в деталях, как обычно. Я бы не смог сдизайнить функциональный dsl, удобный и эффективный для трансляции в plpgsql какой-нибудь.
Да и проверил недавно у постгреса размер стека на рекурсивные вызовы, порядка 1000 для функций, берущих простой int. То есть, компилировать надо во что-то очень императивное.
Ну и конкретно функциональщина там не особо нужна обычно, разве что если поставить цель заменить sql. Но это тоже нехорошо, так как sql весьма таки непростой язык, и есть подозрение, что при обнаружении проблем с эффективностью этих хранимок придётся анализировать сгенерированный код, а то и переписывать его под нужды оптимизатора.
А вот хотя бы нормальная типизация -- уже было бы хорошо.
И ещё вариант, но базоспецифичный: постгрес (и firebird, вроде; и оракл) умеют линковать нативный код, предоставляя ему возможность смотреть в данные, выполнять sql, возвращать результаты. То есть, вполне можно написать библиотеку для любимого языка программирования, которая будет предоставлять хранимые процедуры.
no subject
Date: 2012-02-10 01:02 pm (UTC)firebird только с версии 3.0, которая пока еще только в альфе
(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2012-02-10 12:54 pm (UTC)no subject
Date: 2012-02-10 01:29 pm (UTC)1) в ХП имеет смысл хранить только магастабильную логику. То есть такую которую не только не надо менять часто то никому в голову и не прийдёт её поменять
2) если оставляем ХП они должны быть жёстко документированы, и когда это типа "API" вызывает логика приложения повыше это должно выглядеть просто... ну как запрос к базе
3) В ХП стоит оставлять то что там быстрее, всякие аггрегирующие функции, которые на "крутых" языках будут выглядеть красиво но выполняться долго
На кровавой практике ХП я предлагаю оставлять там, где нет времени переписать и логика не документирована :) ХП самая "забываемая" область, работает и работает десятилетиями, кто их кодировал давно уже "не с нами", документации ноль, тронь такое - надо реверс энжинирить, а для этого с мозгами девелоперы нужны.
no subject
Date: 2012-02-10 02:16 pm (UTC)no subject
Date: 2012-02-11 08:56 am (UTC)Сейчас, я, конечно не так однозначно настроен, есть интернет и т.п.
Сейчас мой подход - полностью отделять логику от БД - отдельный модуль, кот. отвечает за связь с базой.
На вопросы "а если мне вдруг нужно будет выполнить какой то SQL запрос" - я отвечаю - "добавляете метод в модуль и в нем делаете в нем любые запросы".
Правда, с отчетами так не получается - отчеты полностью "базозависимы".
Как то так ;-)
no subject
Date: 2012-02-12 05:32 am (UTC)no subject
Date: 2012-02-15 10:18 am (UTC)