Сколько параметров хранимой процедуры слишком много?

12

Я только начал писать хранимую процедуру в SQL Server 2008 и имеет более 30 параметров. Я никогда не писал один с более чем 10 параметрами, и это заставило меня задуматься ... В какой момент слишком много параметров?

Для контекста ... эта процедура по существу вставит одну строку в одну таблицу. Также было бы очень похоже; хотя несколько меньше; версия, которая выполняет ОБНОВЛЕНИЕ для той же таблицы. Большинство столбцов относительно маленькие с сочетанием int и strings ( varchar(200)).

Каковы проблемы; хорошо или плохо; чтобы иметь процедуру с большим количеством параметров и какой порог, где я должен начать рассматривать другие шаблоны?

— JoeGeeky
источник

1

Это как «если вы спросите цену, вы не можете себе это позволить». Если вы начинаете задаваться вопросом, сколько параметров слишком много, у вас их слишком много. Основной проблемой является не движок, а вы, человек, читающий / сопровождающий код. Так что я бы сказал, что можно иметь как можно больше в автоматически сгенерированном коде , но держать его разумно в написанном / поддерживаемом коде.

— Ремус Русану

12

Вопросы? Я бы не стал спорить.

Лимит 2100 параметров . IIRC это был 2100 начиная с SQL2000, но ошибка в документации показала, что это было 1024.
Если таблица имеет 1000 столбцов (например, из-за расстановки разреженных столбцов Sharepoint-esque ), и вы осуществляете доступ с помощью хранимых процедур, процедура вставки может иметь 1000 параметров. В этом нет ничего плохого.
Сделайте паузу, чтобы просмотреть схему, когда вы встречаете широкую таблицу (не то, чтобы 30 была особенно широкой). Нередко можно найти таблицы, которые начинались с нормализации жизни, но из-за лени и / или безрассудства расширились до неузнаваемости.
Даже не думайте кратко о передаче набора параметров в виде списка CSV или XML. Ослепляет оптимизатор запросов и экономит мало времени или усилий.
Не проверяйте вручную код клиента, чтобы вызвать процедуру с большим количеством параметров. На помощь придут инструменты генерации кода, такие как шаблоны T4 или CodeSmith .

— Марк Стори-Смит
источник

1

Спасибо за этот ответ, это было очень красиво заявлено. Это прекрасно отвечает на мой вопрос. Жаль, что у них нет значка для использования таких замечательных слов в «Эрудит», как « бездарность »

— JoeGeeky

2

Джо Селко - сторонник длинных списков параметров, о которых он подробно пишет в этой статье из двух частей :

Самый простой ответ - использовать длинный список параметров для построения списков и производных таблиц внутри тела процедуры. Сервер SQL может обрабатывать до 2100 параметров, которых должно быть более чем достаточно для практических целей. SQL Server на самом деле слабак в этом отношении; DB2; может передавать 32К параметров. и Oracle может иметь параметры 64K.

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

Думаю ли я, что эти методы всегда будут лучшим решением? Конечно, нет. В SQL такого нет. Но на это стоит обратить внимание, когда возникнет соответствующая проблема.

— onedaywhen
источник