Quanti parametri della procedura memorizzata sono troppi?

12

Ho appena iniziato a scrivere una procedura memorizzata in SQL Server 2008 e ho oltre 30 parametri. Non ne ho mai scritto uno con più di ~ 10 parametri, e questo mi ha fatto pensare ... A che punto ci sono troppi parametri?

Per il contesto ... questa procedura INSERIRÀ essenzialmente una singola riga in una singola tabella. Ci sarebbe anche un molto simile; anche se un po 'più piccolo; versione che esegue un AGGIORNAMENTO sulla stessa tabella. La maggior parte delle colonne sono relativamente piccole con un mix di int e stringhe ( varchar(200)).

Quali sono i problemi; bene o male; avere una procedura con un gran numero di parametri e qual è la soglia da cui dovrei iniziare a considerare altri schemi?

— JoeGeeky
fonte

1

È esattamente come "se devi chiedere il prezzo, non te lo puoi permettere". Se inizi a chiederti quanti parametri sono troppi, ne hai troppi. Il problema principale non è il motore, ma tu, il lettore / manutentore umano del codice. Quindi direi che è OK avere il maggior numero possibile di codice generato automaticamente , ma mantenerlo ragionevole nel codice scritto / gestito.

— Remus Rusanu,

12

Problemi? Non direi nessuno.

Il limite è di 2100 parametri . IIRC è stato 2100 da SQL2000 ma un errore di documentazione ha suggerito che era 1024.
Se una tabella ha 1000 colonne (ad esempio a causa di una disposizione di colonne sparse di Sharepoint ) e si sta imponendo l'accesso tramite procedure memorizzate, l'inser proc può avere 1000 parametri. Niente di sbagliato in questo.
Fare una pausa per rivedere lo schema quando si incontra una tabella ampia (non che 30 sia particolarmente largo). Non è raro trovare tavoli che iniziarono a normalizzare la vita ma attraverso la pigrizia e / o l'incapacità si sono estesi oltre il riconoscimento.
Non considerare nemmeno brevemente il passaggio di un set di parametri come un elenco CSV o XML. Acceca l'ottimizzatore delle query e consente di risparmiare poco tempo o fatica.
Non avviare manualmente il codice client per chiamare una procedura con un gran numero di parametri. Strumenti di generazione del codice come modelli T4 o CodeSmith in soccorso.

— Mark Storey-Smith
fonte

1

Grazie per questa risposta, è stato affermato molto bene. Questo risponde perfettamente alla mia domanda. Peccato che non abbiano un badge per l'uso di grandi parole Scrabble come " fecklessness "

— JoeGeeky,

2

Joe Celko è un sostenitore di lunghe liste di parametri, di cui scrive in dettaglio in questo articolo in due parti :

La risposta più semplice è utilizzare un lungo elenco di parametri per costruire elenchi e tabelle derivate all'interno del corpo della procedura. Il server SQL può gestire fino a 2100 parametri, che dovrebbero essere più che sufficienti per scopi pratici. SQL Server è in realtà un wimp in questo senso; DB2; può passare parametri 32K. e Oracle può avere parametri 64 KB.

... la lunga lista di parametri è composta da semplici parametri vecchi, il che significa che possono essere utilizzati sia per le uscite che per gli ingressi. È inoltre contenuto in un'istruzione che l'ottimizzatore deve utilizzare.

Penso che queste tecniche saranno sempre la soluzione migliore? Ovviamente no. Non esiste nulla di simile in SQL. Ma vale la pena guardare quando si ottiene un problema appropriato.

— onedaywhen
fonte