Здравствуйте, 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>>