SQL Server — отдельные процедуры против одной процедуры

В системе, которую я разрабатываю, у меня есть выбор: либо использовать одну хранимую процедуру, которая выполняет три связанных задания и не возвращает результата, либо один и тот же набор результатов, но полученный из двух разных таблиц.

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

Запись процедуры в виде трех разных процедур изменила бы работу системы, выполняющей процедуры, но не существенно.

Что я хотел бы знать, так это то, стоит ли производительность, полученная от наличия процедур, которые не имеют разных планов выполнения в зависимости от входных данных, по сравнению с одной процедурой, то есть накладные расходы на вызов базы данных в три раза больше, чем накладные расходы на наличие пересоставлять план производительности в зависимости от обстоятельств?

Спасибо

Грег


sql-server performance stored-procedures
person TheMouster    schedule 19.03.2009    source источник

Ответы (3)


arrow_upward
2
arrow_downward

Вы можете подумать о написании трех отдельных хранимых процедур, но затем вызывать их из одной хранимой процедуры.

person Chris Simpson    schedule 19.03.2009
comment
Для дополнительных бонусных баллов, как НАЗВАНИЕ этого шаблона проектирования? - person Peter Wone; 19.03.2009
comment
ха-ха, я не умею запоминать эти имена. Я понимаю фабричные шаблоны и принципы SOLID, но, хотя концепция остается со мной, имя обычно приходится вызывать с помощью поиска в Google. - person Chris Simpson; 19.03.2009
comment
в целях чистого переполнения стека вам, вероятно, следует отредактировать свой собственный ответ, чтобы раскрыть это неуловимое имя шаблона. - person Chris Simpson; 19.03.2009
comment
Не много знаю о шаблонах проектирования, если вообще что-либо знаю, поэтому понятия не имею, о каком из них вы говорите. Однако как насчет одной процедуры из 3 частей. Я видел, как это делалось раньше, но никогда не делал этого сам, так как удобство сопровождения, казалось, вылетало из окна, и это несколько сбивало с толку. - person TheMouster; 19.03.2009
comment
Рассматриваемые процедуры умножаются на количество объектов в системе. 10 объектов = 40 процедур, 100 объектов, вы получаете картину. Я думаю, что техническое обслуживание станет решающим фактором. - person TheMouster; 19.03.2009
comment
Если бы вы могли написать одну хранимую процедуру, которая вызывает три отдельных хранимых процесса, вы получаете преимущество одного вызова sql, но отдельные логические процессы будут скомпилированы отдельно. Боюсь, я не совсем уверен, что вы говорите о техническом обслуживании. - person Chris Simpson; 19.03.2009
comment
Мне показали пример, когда одна процедура имела три определения в одном файле, и казалось, что вы можете вызывать их по отдельности, используя некую форму оператора двоеточия. Не могу хоть в жизни найти примеры такой ситуации в сети. Может, мне это приснилось. - person TheMouster; 19.03.2009
comment
Что касается обслуживания, у меня возникла ситуация, когда в моей системе есть множество объектов, которые используют вариации на эту тему. Поддержка нескольких процедур для одного объекта становится головной болью. Гораздо проще иметь дело с 1 процедурой на объект, чем с 4. - person TheMouster; 19.03.2009
comment
Вы правы насчет правильных трех и вызывающего абонента, планы будут храниться по отдельности и дадут мне желаемую производительность с простотой единой точки доступа, но в итоге я должен изменить 4 вещи, если определение связанные изменения объекта. Возможно, я смогу сгенерировать некоторые из них. - person TheMouster; 19.03.2009
comment
Теперь я понимаю. Какой бы метод вы ни выбрали, вы намерены повторять этот шаблон много раз. Генерация кода может быть шагом вперед, хотя, если вы намерены смотреть в будущее, может быть, ORM может помочь? - person Chris Simpson; 19.03.2009

arrow_upward
2
arrow_downward

Крис Симпсон правильно понимает применимость шаблона проектирования, который я предоставляю ему для выбора. Преимущество, получаемое непосредственно от применения этого шаблона, заключается в простоте, которая обеспечивает легкость проверки (тестирования) и легкость обслуживания.

Производительность может повыситься, но это непредсказуемо. Иногда сложность сбивает с толку оптимизатор плана запроса. Разбивая ваш сверхметод на несколько более простых стратегий для конкретных случаев (подсказка для Криса), может уменьшить количество ошибок, возникающих из-за агрессивной обрезки очень большого дерева решений, а также может разрешить в каждом случае оптимизация. Когда «особый» случай на самом деле очень типичен, это может быть чрезвычайно полезным.

Тем не менее, улучшенная проверяемость и ремонтопригодность сами по себе являются похвальными целями.

person Peter Wone    schedule 19.03.2009

arrow_upward
0
arrow_downward

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

Как правило, чем больше у вас SP, тем больше нужно поддерживать (я чувствую, что на каждый SP приходится немного накладных расходов в дополнение к содержимому, содержащемуся в SP).

person pearcewg    schedule 19.03.2009
comment
Ни один из функциональных сегментов нельзя использовать повторно, что помогает ответить на мой вопрос. Однако процедуры будут повторяться для различных объектов в моей системе, но нет никакого обобщения, которое можно было бы применить к процедурам. - person TheMouster; 19.03.2009
comment
Следовательно, это означает, что у меня будет несколько процедур, где я мог бы провести одну. В результате снизится ремонтопригодность. - person TheMouster; 19.03.2009