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

[metaclass]

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

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

Comments

[blackyblack.livejournal.com]

Избавляться нужно, а как - не знаю. Можно сделать что-то типа курсора по набору данных, но если внезапно начнет тормозить, то ничего кроме обратно переноса логики на сервер придумать не получится.

[oldmann.livejournal.com]

вообще, ребе, в кровавом энтерпрайзе делать бизнес-логику на хранимых процедурах считается хорошим тоном - это даёт портабельность.

[freedom_of_sea.livejournal.com]

мне тоже не нравятся эти недоязыки

[freedom_of_sea.livejournal.com]

портабельность ? С оракла на MSSQL например?

[falcrum.livejournal.com]

Ну, свои нюансы тоже есть, но лучшего действительно не видно. Впрочем, сейчас придёт theiced и расскажет, что это - никому нафиг не надо потому, что он так не делает. :)

[avnik.livejournal.com]

А так же адъ апгрейда всей этой трахомудии внутре сервера.

[vp.livejournal.com]

наоборот как раз таки. Ты получаешь такой адов сервер-локед, что с него никогда никуда не спрыгнешь. Ну и все, как написал метакласс: хреновая (читай: никакая) отладка этого дела.
Как там в ораклах с отладкой ХП?

[plumqqz.livejournal.com]

Господи! не в ярости Твоей обличай меня и не во гневе Твоем наказывай меня.
Честно говоря, совершенно не понимаю, почему вариант с данной господом нашим нам в назидание и епитимью рубой выглядит лучше, чем "турбопаскаль с sql".
Нахуа нужен такой же епитимиальный LINQ, когда есть sql (не вообще есть, а вот тут, под рукой, на, бери и пользуйся) - тоже совершенно непонятно.

[zelanton.livejournal.com]

Посмотри например MSSQL Express вместо Firebird. Миграция - дело решаемое, а потом писать скрипты становится много проще.

И помнится когда-то давно у нас был срач я говорил, что сделал так изначально, а ты мне доказывал что так делать нельзя - теряется скорость работа кода сильно нагруженного SQL запросами. Могу правда ошибаться что это был именно ты.

[plumqqz.livejournal.com]

Как там в ораклах с отладкой ХП?

Вопросом, стало быть, не интересовались.
"Рассуждай токмо о том, о чем понятия твои тебе сие дозволяют. Так: не зная законов языка ирокезского, можешь ли ты делать такое суждение по сему предмету, которое не было бы неосновательно и глупо?"

[inv2004.livejournal.com]

Как обычно kx побеждает: база и язык в одном флаконе - делить нет смысла. опердень (но не логика) на java - не неё лёгким движением руки встраивается kx.

Ну а в целом я за хранимые: меньше всяких ненужных взаимодействий и сущностей и, в итоге, поддерживать и отлаживать проще.

[blackyblack.livejournal.com]

Хотя Ваши комментарии - традицонно адский ад, но тем не менее, присоединяюсь.

[fas-tm.livejournal.com]

Я думаю вы видели такие продукты :) Там примерно несколько тысяч хранимок, причем больше половины - это различные версии оставленные для совместимости, различные кастомные хранимки которые просто переносятся от заказчику к заказчику и не удаляются потому что уже никто не знает какая из них работает а какая нет. Взаимосвязь этих хранимок/триггеров/вьюх - это пазл, который при интеграции собирается месяцами. Плюс обычно там с десяток новых типов данных определенно помимо стандартных, без описания и прочий трэш.
По моему, база данных с логикой внутри - это просто адский ад :)

[stdray.livejournal.com]

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

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

[oldmann.livejournal.com]

портабельность - с x86 на POWER или SPARC, и обратно.

[fraks-nsk.livejournal.com]

"и kinterbasedb вроде живой".

На сколько я понял - не то что бы живой а просто еще не до конца умер.
А вот его автор - как раз вроде умер, а нового не появилось.
Оно вроде пока поддерживает последние версии FB, но вот последнюю версию самого питона - вроде как уже не поддерживает.
И это печально.

Помечтать можно о другом - что бы SP можно было писАть на нужном тебе ЯП.
Вроде даже были какие-то тесты на этот счет, можно глянуть на то что там в тройке обещают...

[fraks-nsk.livejournal.com]

Зато производительность на сервер-сайд решении обычно существенно лучше выходит.
Я многие процедуры которые ранее делал на клиенте перетаскиваю на сервер - получается в разы быстрее и проще.

[metaclass.livejournal.com]

В ораклах как раз хорошо :)

[metaclass.livejournal.com]

Собственно SQL запросы - ок.
Отсутствие их reuse нормального - не ок.
Версионирование хранимых процедур и прочая, особенно в Firebird - анус кромешный.

[metaclass.livejournal.com]

Срач был когда-то, да. Не помню, какую из сторон я тогда защищал, потому что я до сих пор не могу решить, что лучше - бизнес-логика внутри СУБД или дурь с ORM и прочим.
Языки, пригодные для того, чтобы делать бизнес-логику так же эффективно как внутри сервера, не очень массовы.

[metaclass.livejournal.com]

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

[fraks-nsk.livejournal.com]

Все правда :)
Однако
- описания никто не заставляет НЕ делать. Я вообще все документирую прямо в базе. Ибо.
- логика снаружи если программ более одной - тоже не особо фонтан. Так в базе поменял - везде поменялось.

По поводу взаимосвязи - иногда хочется что бы была возможность компилить исходник проги и исходник базы, что бы ошибки в рантайме не всплывали если к примеру в запросе ошибся или имя поля с опечаткой, и увидеть все зависимости...

Подумываю в некоторые процедуры вставить логгер что бы выяснить используются они или нет :)

[si14.livejournal.com]

kx это которой k/q? там же язык п-ц и цена космическая, нет?

[si14.livejournal.com]

Постгря умеет бидон в качестве хранимок.

[altmind.livejournal.com]

надо избавляться от хранимых процедур таких, как они сделаны в РСУБД. У меня есть большая вера в хранимые процедуры, сделаные как в mongodb - на general purpose языке. Ну и вера в CQRS.