Лучше написать целевую хранимую процедуру с меньшим количеством параметров?

Question

Скажем, у меня есть хранимая процедура, которая возвращает данные из запроса SELECT. Я хотел бы получить немного другие результаты в зависимости от того, через какие параметры я прохожу. Мне интересно, лучше ли иметь несколько хранимых процедур, которые принимают один или нет параметров для этого (например, GetXByDate или GetXByUser), или одну хранимую процедуру с несколькими параметрами, которая делает много (например, GetX)?

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

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

Что вы используете в своих решениях и почему?

Answer 1

Я бы относился к хранимым процедурам так же, как к методу класса. Это должно сделать одну вещь и сделать это просто. Попробуйте применить те же правила рефакторинга / запаха кода к хранимым процедурам, что и к коду приложения.

Answer 2

Чем сложнее хранимые процедуры, тем сложнее компилировать сервер SQL правильно и быстро и эффективно выполнить.

Даже в большой хранимой процедуре вам нужно либо иметь несколько копий запроса, либо добавить в него множество CASE и IF, которые снижают производительность. Таким образом, вы не очень-то выигрываете от того, что смешиваете все вместе.

Исходя из моего личного опыта, я также считаю, что большой SQL-код sp с большим количеством веток сложнее поддерживать, чем несколько небольших и простых sprocs.

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

Сказав, что, если вам не важна производительность (приложение для интрасети, запросы не такие уж и тяжелые, выполняйте их не так часто), вам может пригодиться универсальный sproc.

Answer 3

Я второй @tvanfosson.

Однако я хотел бы добавить, что вы можете сделать и то и другое: иметь многофункциональный sproc (например, GetX), который содержит основную логику для целого класса запросов, и заключить его в серию меньших sprocs (GetXY, GetXZ ), которые выполняют большой, передавая соответствующие параметры.

Это означает, что вы не повторяете себя, но вы также можете предоставить простой интерфейс для клиентских приложений: приложение, которое только когда-либо вызывает GetXY, не должно знать о GetXZ.

Мы иногда используем этот подход.

Answer 4

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

Конечно, если у вас есть более сложные хранимые процедуры, это может быть не так. GetAndProcessXByDate может быть лучше уменьшен до GetXByDate, GetXByUser, ... которые вызывают другой сохраненный процесс ProcessX.

Так что я думаю, что окончательный ответ: это зависит ... :)

Answer 5

Подход AJs дает вам лучшее из обоих миров. Боль от необходимости поддерживать повторяющийся код для нескольких sprocs не может быть преувеличена.

Сборка модулей Sproc и UDF для общего использования и вызов их из специальных задач.

Answer 6

Одно преимущество одного хранимого процесса, если вы используете сгенерированный слой доступа к данным C #, такой как LinqToSQL, генерируется один класс для представления вашего набора результатов.

Answer 7

Кто / что будет вызывать эти хранимые процедуры? Я бы не стал писать хранимые процедуры для операторов SELECT именно потому, что вам может понадобиться множество различных операторов SELECT, в том числе объединения с другими таблицами и т. Д.