Бизнес-логика в хранимых процедурах
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 10:59 am (UTC)Вернее есть случай, когда ХП не очень катят, если это аналитическая прилада, где запросы генерятся на лету, но я так понимаю это не ваш случай.
И еще, лично я воспринимаю SQL как язык манипулирования а не язык программирования. Вот здесь и должен быть водораздел между двумя крайностями "вся логика в ХП" и "вся логика на клиенте".
Да и зачем уходить от более совершенной декларативной пардигмы в каменный век императивного программирования? Неее....
no subject
Date: 2012-02-10 11:12 am (UTC)no subject
Date: 2012-02-10 11:24 am (UTC)Думаю, имеет смысл обсуждать конкретную проблему/задачу и как ее лучше решить. Многие из отписавшихся идею отказа от ХП не поддержали.
Помимо удобства программирования есть жеи другие факторы:
Безопасность БД. С ХП ее можно обеспечить в сложных оперденях. Далее ее можно так-же и контроллировать. В больших организациях обложенных всякими требованиям по управлению IT/безопасностью это очень важно. Лично я как безопасник запорю любое решение, которое дает с базой работать напрямую.
И еще есть такой фактор, что разработчики конечных приложений (гуй/ввод-вывод) все более примитивизируются, посему надеяться на их вменяемость сложно. Поэтому идея разделения сложной системы на слои, которые взаимодейсвуют между собой только через оговоренные API-интерфесы - проверенный временм путь. В операционках ядро пишут одни люди, а блокнот и рисовалку - другие. И уровень у ни разный. Аналогично во всем остальном, даже идея инкапсуляции в ООП - тоже самое.