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?

sql-server-2008 database-design performance optimization 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

Odpowiedzi:

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