Пишут долго хранимые procs признак плохой конструкции базы данных и стиля кодирования?

Question

Я встречался с одним человеком, который утверждает, что он написал более 5000 строк хранимой процедуры на сервере Sql. Должна ли эта длительная хранимая процедура вообще понадобиться? Или это признак плохой базы данных и дизайна кодирования? Я действительно волнуюсь. Я никогда не писал ничего длинного, чем 100 строк кода в Хранимой процедуре, в одном из моих живых проектов, основанных на страховании, которые должны были иметь дело с Аккордами и Дополнениями США. Кстати, он хвастался, как если бы он отлично справлялся с написанием такой длительной хранимой процедуры.

Заранее спасибо :)

В ожидании ваших ответов.

Answer 1

Из моего личного опыта, есть несколько условий, которые заставляют вас писать такую ​​длинную хранимую процедуру, это 2 из тех, что я помню сейчас

• плохой дизайн базы данных (как вы уже упоминается)
• большая сложная формула для вычисления очень и очень н сложным, отчеты и т.п. (например, Human Resources - Оставить управление)

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

Answer 2

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

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

Он мог бы написал

SELECT 
* 
FROM 
TABLE 
AS 
t 

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

Суть в том, что я не думаю, что длина является хорошей метрикой, чтобы определить, хорош или плох sproc. Вероятно, вы можете написать 100 строк sproc, который хуже, чем 5000 строк sproc.

Если бы я лично смотрел на свой новый 5000 строк sproc, я был бы обеспокоен и не гордился, даже если бы не было другого выбора. Поддержание этого будет кошмаром.

Но в вашем случае друзья трудно комментировать в любом случае, не зная, какое действие выполняет sproc или как оно это делает.