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

22

Poiché varchar occupa spazio su disco proporzionale alla dimensione del campo, c'è qualche motivo per cui non dovremmo sempre definire varchar come il massimo, ad esempio varchar(8000)su SQL Server?

Sul tavolo di creazione, se vedo qualcuno che varchar(100)lo fa, dovrei dire loro che hai torto che dovresti fare varchar(8000)?

sql-server varchar

— Aleksandr Levchuk
fonte

Penso che qui dobbiamo distinguere tra l'uso nella tabella di creazione e l'uso nelle dichiarazioni dei parametri delle procedure memorizzate. Per la seconda interpretazione vedi la mia domanda dba.stackexchange.com/questions/1772/…

— bernd_k

18

La lunghezza è un vincolo per i dati (come CHECK, FK, NULL ecc.)
Prestazioni quando la riga supera 8060 byte
Non può avere vincoli o indici univoci (la larghezza della colonna chiave deve essere <900)
L'impostazione predefinita è SET ANSI PADDING ON = possibilità di memorizzare molti spazi finali
SQL Server assumerà una lunghezza media di 4000 per le operazioni di ordinamento, allocando la memoria in base a questo (è necessario trovare un collegamento per eseguire il backup ma arrugginirmi mentre lo faccio :-)

Riepilogo: non farlo.

— GBN
fonte

Prestazioni quando la riga supera 8060 byte . Ciò si riferisce ai byte effettivamente utilizzati e non ai byte massimi consentiti?

— bernd_k,

@bernd_k: 8060 = la più grande quantità di dati per una riga che si adatta a una singola pagina 8192. Includi spese generali di riga. Resto (132 byte) = sovraccarico di pagina

— gbn

Ciò significa che le prestazioni diminuiscono quando viene utilizzata la dimensione più grande, non per il solo fatto, che è consentito l'uso.

— bernd_k,

@bernd_k: qualsiasi riduzione delle prestazioni è causata da 1. allocazione della memoria per specie ecc. 2. Overflow di riga (> 8060 byte). Il fatto di avere 10 caratteri in ogni varchar (8000) è irrilevante fino a quando non vengono soddisfatte queste condizioni (SQL avviserà in seguito di potenziali errori per le chiavi di indice)

— gbn

L'ordinamento di una tabella con una colonna varchar (100) riempita con campi di lunghezza di 100 byte merita un'altra domanda, poiché l'ordinamento assume una media di 50 caratteri?

— bernd_k,

7

Supponendo che ti riferisci a SQL Server, posso pensare a uno.

Esiste un limite alla dimensione (8 KB) di una riga in una tabella e SQL consente di definire campi varchar che potrebbero teoricamente superare tale limite. Quindi l'utente potrebbe ricevere errori se mettesse troppi dati nel campo relativo a quello.

A partire da SQL 2K8 è possibile superare questo limite, ma ci sono implicazioni sulle prestazioni .

Inoltre, esiste un controllo completo della ragionevolezza per limitare le dimensioni a come si aspettano i dati. Se vuoi un campo di lunghezza illimitata, perché non andare con text o ntext?

— JohnFx
fonte

quindi i tipi di dati text e ntext sono memorizzati in un modo che non influisce sulle prestazioni?

— Chad,

Questi tipi non contribuiscono tanto al limite della dimensione della riga di 8 KB su una tabella perché i dati effettivi vengono archiviati in una tabella separata sotto le copertine anziché in linea con il resto delle colonne. C'è ancora un impatto sulle prestazioni, ma per diversi motivi. Ci sono anche limitazioni sul supporto delle funzionalità in questi campi rispetto a varchar e nvarchar

— JohnFx,

text e ntext sono deprecati a favore di varchar (max).

— Phil Helmer,

3

Sicuramente dipende da quali informazioni vengono memorizzate nel campo?

Alcune cose avranno una lunghezza massima per una serie di motivi e se deve esserci una lunghezza massima, quella dovrebbe essere la lunghezza del campo.

Se teoricamente non esiste una lunghezza massima, mi chiederei perché varchar sarebbe usato.

— Toby
fonte

3

Nel contesto dei database Oracle ho appreso che usare sempre la dimensione del campo più piccola per le colonne del database ha un insulto.

Quando si spostano i dati tramite esportazione di importazione da un database con regole di confronto a byte singolo in uno con regole di confronto a più byte (come Oracle XE), la lunghezza in byte può aumentare e l'importazione dei dati nelle tabelle create dall'importazione non riesce. Ovviamente Oracle ha la possibilità di definire la lunghezza di varchar2 come char o byte.

Il mio punto qui è che non è sempre saggio definire il campo con il più piccolo possibile. Ho visto molte tabelle alter per aumentare il campo in seguito (causato da requisiti cambiati).

Avere il 20% - 100% di campo inutilizzato con è un'opzione discutibile qui.

— bernd_k
fonte