metaclass: (Default)
[personal profile] metaclass
Софт1: написан почти целиком мной, заказной: 186 таблиц, 169 хранимых процедур
Софт2: написан мной и ребе белнетмоном, коробочный: 74 таблицы, 40 хранимых процедур

Date: 2010-08-27 08:39 am (UTC)
From: [identity profile] fraks-nsk.livejournal.com
Засунув процедуру которая работает с большим кол-вом данных в хранимку можно значительно ускорить работу. Иногда - очень значительно.

Меньше таскать данных по сетке. Иногда имеет значение.

Можно давать права на процедуры но не на таблицы.

Рефакторинг. Засовываешь логику в процедуру - место с логикой одно, из какого софта бы не коннектился. Если прога работающая с базой не одна - то это удобно.

Контроль за рукоблудством. В процедуре можно проконтролировать вводимые данные.

И прочее, прочее, прочее...

Отсутствие SP в СУБД а равно неиспользование имеющейся возможности сделать SP как правило говорит от недостаточном владении инструментом.

Date: 2010-08-27 08:48 am (UTC)
From: [identity profile] metaclass.livejournal.com
Это хорошо в серверах с гуманными языками для хранимых процедур.

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

Date: 2010-08-27 09:12 am (UTC)
From: [identity profile] fraks-nsk.livejournal.com
Firebird - это как раз сервер с гуманным языком СП :)

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

Именно поэтому такую логику удобно засовывать в SP.

Date: 2010-08-27 09:14 am (UTC)
From: [identity profile] metaclass.livejournal.com
Не всегда. Например, нельзя сделать полиморфную по типу записи/курсора хранимую процедуру, из-за чего приходится или руками дублировать код, или выражать требуемое на более подходящем языке а затем генерировать из него хранимые процедуры (что я как раз сейчас и делаю).

Date: 2010-08-27 09:27 am (UTC)
From: [identity profile] fraks-nsk.livejournal.com
>>полиморфную по типу записи/курсора хранимую процедуру

Можно примерчик а то не догоняю про что конкретно речь?

Date: 2010-08-27 09:42 am (UTC)
From: [identity profile] metaclass.livejournal.com
Ну реализовать виртуальную функцию, тайпкласс или еще какой-нибудь подобный тип полиморфизма.

Т.е. у нас например есть автоматизация предприятия, состоящего из десятка филиалов. Все записи в БД помечаются кодом филиала (Dept). Например есть три таблицы Clients(Dept int,...), Payments(Dept int,...), Sales(Dept int, ...). С точки зрения типизации это означает что все три сущности реализуют один и тот же интерфейс или тайпкласс Dept a where dept :: a -> int

Пользователи системы тоже относятся к филиалам, т.е. есть таблица UserDepts(user,dept) И мне нужно, чтобы пользователи видели только записи своего филиала. Сейчас это реализуется созданием для каждой из таблиц соответствующего view (или selectable хранимой процедуры) и фильтрацией в нем, причем код проверки везде дублируется типа (where exists(select 1 from UserDepts where UserDepts.user=current_user and UserDepts.dept=SomeTableName.dept))
Могут быть и более сложные условия, например чтобы пользователь видел только записи по относящемуся к нему клиенту, итд.

И вот эту копипасту было было желательно выпилить в отдельную функцию и проверять все в ней единообразно, а не дублировать.

Date: 2010-08-27 10:04 am (UTC)
From: [identity profile] fraks-nsk.livejournal.com
Код проверки можно попробовать вынести с помощью EXECUTE STATEMENT - что бы собирать запрос проверки и подсовывать в него имя таблицы.

Но конечно это не объектность обычных языков программирования, да.

В моей системе пока не так много таблиц что бы подобная копипаста радикально напрягала.

Date: 2010-08-27 10:10 am (UTC)
From: [identity profile] fraks-nsk.livejournal.com
А кстати можно сделать по другому сделать доп. таблицу в которой для каждой записи в подопытных таблицах завести запись. И Dept писАть только в эту таблицу. На нее сделать вьюху с ограничениями.
На подопытные таблицы сделать вьюхи с условием что exists в доп. таблице.

Конечно не факт что от этого не будет нести крышу у оптимизатора, но зато проверка в одном месте :)

Date: 2010-08-27 10:13 am (UTC)
From: [identity profile] metaclass.livejournal.com
Да, я так и делаю, это имитация наследования поверх таблиц.
Печаль начинается, если для проверки информации о подразделении недостаточно - например если информация о клиенте есть только в части связанных таблиц, начинается страшенное вуду.

В общем, язык SP не дотягивает даже до минимальных ООП языков, не говоря уже о функциональных.

Profile

metaclass: (Default)
metaclass

April 2017

S M T W T F S
      1
2345678
9101112 131415
16171819202122
23242526272829
30      

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Oct. 1st, 2025 07:40 am
Powered by Dreamwidth Studios