![[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
no subject
no subject
no subject
no subject
no subject
Как там в ораклах с отладкой ХП?
no subject
Вопросом, стало быть, не интересовались.
"Рассуждай токмо о том, о чем понятия твои тебе сие дозволяют. Так: не зная законов языка ирокезского, можешь ли ты делать такое суждение по сему предмету, которое не было бы неосновательно и глупо?"
no subject
Я многие процедуры которые ранее делал на клиенте перетаскиваю на сервер - получается в разы быстрее и проще.
no subject
no subject
no subject
По моему, база данных с логикой внутри - это просто адский ад :)
no subject
Однако
- описания никто не заставляет НЕ делать. Я вообще все документирую прямо в базе. Ибо.
- логика снаружи если программ более одной - тоже не особо фонтан. Так в базе поменял - везде поменялось.
По поводу взаимосвязи - иногда хочется что бы была возможность компилить исходник проги и исходник базы, что бы ошибки в рантайме не всплывали если к примеру в запросе ошибся или имя поля с опечаткой, и увидеть все зависимости...
Подумываю в некоторые процедуры вставить логгер что бы выяснить используются они или нет :)
no subject
Да правда. Пару раз было c большими комментариями. На французском и немецком :)
>>логика снаружи если программ более одной - тоже не особо фонтан.
>>Так в базе поменял - везде поменялось.
И везде все упало :) Тоже бывало :)
no subject
с оговорками
no subject
no subject
А вот ORM - это действительно портабельность. Вообще пофигу, где и как данные лежат.
no subject
соответственно, если бизнес-логика сделана на хранимых процедурах, я могу безболезненно менять платформу, в диапазоне от x86 и Itanium, до IBM POWER, от HP-UX до AIX.