Larghezza colonna VARCHAR di SQL Server

Cercando sul Web, ho trovato consigli contrastanti sul fatto che vi sia un impatto sulle prestazioni quando si specificano colonne VARCHAR troppo ampie, ad esempio VARCHAR (255), quando probabilmente VARCHAR (30) lo farà.

Sono costantemente d'accordo sul fatto che si verifichi un calo delle prestazioni se l'intera riga supera 8060 byte. A parte questo, vedo disaccordo.

L'affermazione è vera The default is SET ANSI PADDING ON = potential for lots of trailing spaces? Finché la larghezza totale della riga è inferiore a 8060, ci sono problemi di prestazioni reali nel sovradimensionamento delle colonne VARCHAR?

Prova che la larghezza della colonna è importante

The same goes for CHAR and VARCHAR data types. Don’t specify more characters in character columns that you need.

http://www.sql-server-performance.com/2007/datatypes/

• Length is a constraint on the data (like CHECK, FK, NULL etc)
• Performance when the row exceeds 8060 bytes
• Can not have unique constraint or index (key column width must be < 900)
• The default is SET ANSI PADDING ON = potential for lots of trailing spaces

Quali sono le conseguenze dell'impostazione di varchar (8000)?

Prova che la larghezza della colonna NON ha importanza

If you're talking about varchar and nvarchar then no, there is no penalty for allowing a higher field length.

/programming/7025996/overstating-field-size-in-database-design

The varchar datatype, by contrast, consumes only the amount of actual space used plus 2 bytes for overhead

http://sqlfool.com/content/PerformanceConsiderationsOfDataTypes.pdf

La domanda potrebbe essere meglio formulata come:

"Qual è il vantaggio di specificare eccessivamente la lunghezza massima di una colonna a lunghezza variabile?"

In generale, ci sono pochi vantaggi e numerosi svantaggi, come sottolineano le varie risposte collegate. A parte qualsiasi altra preoccupazione, considera che SQL Server non è open-source: ci sono molti "numeri magici" ed euristica applicati in base alle informazioni fornite al sistema. Senza l'accesso al codice sorgente, non potremmo mai essere completamente sicuri dell'impatto di questa pratica.

In alcuni casi , in cui la lunghezza media di una colonna è significativamente superiore al 50% assunto da SQL Server durante il calcolo delle concessioni di memoria di ordinamento / hash, è possibile che si verifichi un miglioramento delle prestazioni specificando in eccesso la lunghezza massima. Questa è una soluzione dubbia , e probabilmente dovrebbe essere applicata solo da un esplicito CASTo CONVERT(con commenti!) Piuttosto che cambiare la definizione della colonna di base. A volte, sarà preferibile riscrivere la query per ordinare le chiavi invece di intere righe.

Laddove la dimensione massima della riga potrebbe superare il limite in riga (anche se nessuna riga lo fa effettivamente), l'eliminazione delle righe può causare una suddivisione imprevista della pagina se è presente un trigger. Gli aggiornamenti possono anche portare alla frammentazione tramite lo stesso meccanismo.

SQL Server fa un ottimo lavoro nella maggior parte dei casi in cui viene fornito con informazioni valide e accurate dai metadati. Compromettere questo principio per "praticità" mi sembra poco saggio. Un approccio ragionevole è quello di scegliere un valore di lunghezza massima ragionevole in base ai dati effettivi da memorizzare e alle eventuali modifiche prevedibili.

Come indicato, purché la dimensione della riga non superi 8060 (o qualunque sia il valore massimo impostato), non vi sono differenze di prestazioni nell'uso di VARCHAR (30) o VARCHAR (255) o superiore. Il confronto da CHAR a VARCHAR dall'articolo collegato non è realmente pertinente. Anche se sono d'accordo che non dovresti specificare più spazio di quello che sei sicuro di aver bisogno, in molti casi non sai solo di quanto spazio avrai effettivamente bisogno. Quindi sii liberale con lo spazio VARCHAR - Sono abbastanza sicuro che aumentare la dimensione dei campi richiede una ricostruzione della tabella, mentre diminuire è una semplice istruzione ALTER TABLE.