Ile parametrów procedury składowanej jest zbyt wiele?

12

Właśnie zacząłem pisać procedurę przechowywaną w SQL Server 2008 i mam ponad 30 parametrów. Nigdy nie napisałem takiego z więcej niż ~ 10 parametrami, co skłoniło mnie do myślenia ... W którym momencie jest zbyt wiele parametrów?

Dla kontekstu ... ta procedura zasadniczo WKŁADUJE pojedynczy wiersz do pojedynczej tabeli. Byłoby też bardzo podobne; choć nieco mniejszy; wersja, która wykonuje aktualizację na tym samym stole. Większość kolumn jest stosunkowo niewielka z kombinacją liczb całkowitych i ciągów ( varchar(200)).

Jakie są problemy; dobry czy zły; do procedury z dużą liczbą parametrów i jaki jest próg, od którego powinienem zacząć rozważać inne wzorce?

— JoeGeeky
źródło

1

Jest dokładnie tak, jak „jeśli musisz zapytać o cenę, nie możesz sobie na to pozwolić”. Jeśli zaczniesz się zastanawiać, ile parametrów jest za dużo, masz ich za dużo. Głównym problemem nie jest silnik, ale ty, ludzki czytelnik / opiekun kodu. Powiedziałbym więc, że można mieć jak najwięcej w automatycznie generowanym kodzie , ale zachowaj rozsądność w pisanym / utrzymywanym kodzie.

— Remus Rusanu

12

Zagadnienia? Nie będę się kłócić.

Limit wynosi 2100 parametrów . IIRC było 2100 od SQL2000, ale błąd w dokumentacji sugerował, że było 1024.
Jeśli tabela ma 1000 kolumn (na przykład z powodu rzadkiego rozmieszczenia kolumn w stylu SharePoint ) i wymuszasz dostęp za pomocą procedur przechowywanych, twój proces wstawiania może mieć 1000 parametrów. Nic w tym złego.
Zatrzymaj się, aby przejrzeć schemat, gdy napotkasz szeroki stół (nie to, że 30 jest szczególnie szeroki). Często zdarza się, że tabele, które rozpoczęły życie, są znormalizowane, ale dzięki lenistwu i / lub bezczynności wykraczają poza możliwości rozpoznania.
Nawet nie rozważaj krótko przekazania zestawu parametrów jako listy CSV lub XML. Oślepia optymalizator zapytań i oszczędza niewiele czasu i wysiłku.
Nie należy ręcznie przekręcać kodu klienta, aby wywołać procedurę z dużą liczbą parametrów. Narzędzia do generowania kodu, takie jak szablony T4 lub CodeSmith na ratunek.

— Mark Storey-Smith
źródło

1

Dzięki za tę odpowiedź, została bardzo ładnie stwierdzona. To doskonale odpowiada na moje pytanie. To tylko szkoda, że nie mają odznakę za korzystanie z wielkich Scrabble słów takich jak „ fecklessness ”

— JoeGeeky

2

Joe Celko jest zwolennikiem długich list parametrów, o których szczegółowo pisze w tym dwuczęściowym artykule:

Najprostszą odpowiedzią jest użycie długiej listy parametrów do zbudowania list i tabel pochodnych w treści procedury. Serwer SQL może obsłużyć do 2100 parametrów, co powinno być więcej niż wystarczające do celów praktycznych. SQL Server jest w tym względzie mięczakiem; DB2; może przekazać parametry 32 KB. a Oracle może mieć parametry 64 KB.

... długa lista parametrów składa się ze starych, prostych parametrów, co oznacza, że można ich używać zarówno na wyjściu, jak i na wejściu. Jest również zawarty w jednej instrukcji do użycia przez optymalizator.

Czy uważam, że te techniki zawsze będą najlepszym rozwiązaniem? Oczywiście nie. W SQL nie ma czegoś takiego. Ale warto przyjrzeć się, gdy pojawi się odpowiedni problem.

— oneedaywhen
źródło