Re[2]: Хранимые процедуры
От: alexdev Россия http://alexdev-ru.livejournal.com
Дата: 09.02.10 19:16
Оценка:
Здравствуйте, MozgC, Вы писали:

MC>Здравствуйте, alexdev, Вы писали:


A>>1. Есть хранимка (>500 строк) текст которой, это один большой Case. Не лучше ли было вынести каждую ветку кейса, в отдельную хранимку? Думаю, это прибавит производительности.

MC>Производительности прибавит навряд ли, а вот логическое структурирование (декомпозиция) будет лучше. Поддерживать проще будет. Но чтобы точно ответить надо смотреть код хранимки.

код привести не могу, но постараюсь изложить суть
допустим эта процедура с 5 параметрами, код примерно следующий

BEGIN
CASE param1
WHERE 'Get1' THEN ... // 100-200 строк
WHERE 'Get2' THEN ... // 100-200 строк
WHERE 'Get3' THEN ... // 100-200 строк
END CASE;
END;

Я не знаю как хранимка выполняется на сервере, но могу предположить, что примерно также, как и исполняемые файлы. т.е. скомпилированная хранимка, проецируется в память (или она всегда там висит? ) Ну и собственно выполняется. Если она каждый раз проецируется в память, то думаю, что резоннее разбить на несколько..

A>>2. Есть хранимки, которые принимают > 10 параметров, и в коде часто параметрам передается null.. Не проще было бы опять несколько хранимок написать? Как это отражается на безопасности и производительности?

MC>Нужно смотреть конкретный случай. Очень возможно что не проще. Например если ХП делает выборку и если параметр не null, то он участвует в фильтрации, а если не null — то не участвует, т.е. что-то типа
MC>
... AND (SupplierID_ IS NULL OR SupplierID = SupplierID_)
то я бы предпочел как раз такую ХП, а не десять с разными вариациями where-фильтра вместо неё.

точно сказать не могу, но where-фильтров в коде достаточно. Ладно еще когда 10 входных параметров, но когда входных параметров >= 30 ...
... << RSDN@Home 1.2.0 alpha 4 rev. 1436>>
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.