metaclass: (Default)
metaclass ([personal profile] metaclass) wrote2012-02-10 08:28 am

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

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

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

[identity profile] inv2004.livejournal.com 2012-02-10 06:04 pm (UTC)(link)
sql определённо говно, но лучше и без левых сущностей пока мало что есть, тем более уровня ынтерпайз.

[identity profile] inv2004.livejournal.com 2012-02-10 06:08 pm (UTC)(link)
А чем не угоден sql. что на нём нельзя написать, что можно на обычном pl/sql например? да, выглядит не очень "бизнес", но зато чистый sql.

В январе на работе крутил мозг, и итоге заменил много pl/sql одним большим закросом, но с большой вложенностью decode, и не очень даже страшно выглядит даже.

[identity profile] zamotivator.livejournal.com 2012-02-10 07:52 pm (UTC)(link)
Ещё один зомбированный HighLoad++/модой идиот.

[identity profile] metaclass.livejournal.com 2012-02-10 10:17 pm (UTC)(link)
Эта штука не очень удобна. В них даже курсор толком не передашь.

[identity profile] gds.livejournal.com 2012-02-10 11:49 pm (UTC)(link)
вроде бы, если брать модель "писать хранимые процедуры на внешнем языке и линковать их динамически", то не очень-то и нужно передавать из/в этих штук курсоры. Хотя бы потому, что курсор -- это затык для оптимизатора/планировщика, и курсоры единственно полезны в случае, когда идёт построчная обработка записей, опционально с ранним завершением. Если писать хранимые процедуры на внешнем языке, все запросы, которые нужны, можно включать в эту .dll/.so, без курсоров.

[identity profile] si14.livejournal.com 2012-02-11 12:27 am (UTC)(link)
Да я не спорю, что проще, но кривая обучения, имхо, у K таки круче. Плюс к тому — да, бесплатно, но обосновать работодателю необходимость покупки kx будет сложно :)

[identity profile] olegy.livejournal.com 2012-02-11 08:56 am (UTC)(link)
Я для себя году в 2000 решил однозначно, что хранимых процедур в моих проектах не будет. Это после того, как мне несколько месяцев приходилось ездить на объект за 500 км, и в 4 часа ночи (только в это время мне давали 20 минут на остановку работы) менять на сервере код триггеров и процедур.
Сейчас, я, конечно не так однозначно настроен, есть интернет и т.п.
Сейчас мой подход - полностью отделять логику от БД - отдельный модуль, кот. отвечает за связь с базой.
На вопросы "а если мне вдруг нужно будет выполнить какой то SQL запрос" - я отвечаю - "добавляете метод в модуль и в нем делаете в нем любые запросы".
Правда, с отчетами так не получается - отчеты полностью "базозависимы".
Как то так ;-)

[identity profile] darkdrip.livejournal.com 2012-02-11 04:31 pm (UTC)(link)
вы ебанулись? вы TOAD видели? с разработкой и отладкой пиздец

[identity profile] darkdrip.livejournal.com 2012-02-11 04:34 pm (UTC)(link)
писать хранимки на джаве (сисярпе) не рекоммендуется. это еще хуже, чем PL/SQL. нет нормального маппинга сущностей базы на C-подобный язык

[identity profile] gsbelarus.livejournal.com 2012-02-11 05:02 pm (UTC)(link)
это не то. UDF -- просто функция. получает параметры -- возвращает результат. а для полноценной работы с БД надо из нативного кода:

1) иметь доступ к текущему подключению
2) иметь доступ к текущей транзакции
3) возможность создавать и выполнять запросы
4) для триггеров иметь доступ к старой/новой версиям записи

[identity profile] perepertoz.livejournal.com 2012-02-12 05:32 am (UTC)(link)
чот я так понимаю, с тех пор как я в 10 лет тому назад делал на дельфи отображение и редактирование данных бурения (каждый гок считал своим долгом сделать их в своём формате), с тех пор мало что поменялось :)))

[identity profile] nivanych.livejournal.com 2012-02-12 12:18 pm (UTC)(link)
Монаду не написать!!

[identity profile] inv2004.livejournal.com 2012-02-12 06:18 pm (UTC)(link)
Задача - решить проблему. все остальные супутствующие проблемы - не мои :)

[identity profile] altmind.livejournal.com 2012-02-13 05:52 am (UTC)(link)
поясните

[identity profile] zamotivator.livejournal.com 2012-02-13 06:10 am (UTC)(link)
Простое утверждение - человек, утверждающий что MongoDB чем-то лучше MySQL/PostgreSQL либо теоретик, либо никогда не использовал эту базу под нормальной нагрузкой.

[identity profile] altmind.livejournal.com 2012-02-13 06:36 am (UTC)(link)
я говорю о преимуществе general purpose языка перед (*)-SQL, а не о монге.

кстати, да, я так и не нашел области, куда можно эту монгу приткнуть.

[identity profile] zamotivator.livejournal.com 2012-02-13 06:58 am (UTC)(link)
Приношу свои извинения за поспешные суждения.

А general purpose языки, как было замечено, вполне доступны как минимум в PostgreSQL

[identity profile] serbod.livejournal.com 2012-02-15 10:09 am (UTC)(link)
Эмм.. Хранимые процедуры ведь от конкретной СУБД зависят, да еще и между версиями могут отличаться. SQL и тот вроде как стандартный, но у каждого со своими шлюхами.

А вот ORM - это действительно портабельность. Вообще пофигу, где и как данные лежат.

[identity profile] oldmann.livejournal.com 2012-02-15 10:11 am (UTC)(link)
в кровавом энтерпрайзе есть только две СУБД - много Oracle и чуть-чуть DB2.
соответственно, если бизнес-логика сделана на хранимых процедурах, я могу безболезненно менять платформу, в диапазоне от x86 и Itanium, до IBM POWER, от HP-UX до AIX.

[identity profile] serbod.livejournal.com 2012-02-15 10:18 am (UTC)(link)
Я бы выбрал ORM для бизнес-логики и SQL (или надстройку над ним) для отчетов. А ХП пусть ORM создает и пользует по своему усмотрению.

Page 3 of 3