sopravvalutazione delle dimensioni del campo nella progettazione del database

Ho alcuni campi per le mie tabelle che sono stringhe e al momento, la maggior parte delle dimensioni del campo hanno limiti di caratteri piuttosto elevati. Ad esempio, 100 caratteri per il nome della via. C'è una penalità per l'utilizzo di campi di grandi dimensioni? Se, ad esempio, cambio il limite a 30 caratteri per questo campo, ci sarà un aumento delle prestazioni o un'efficienza con le dimensioni? Ci sarebbero circa 50 campi che potrebbero essere candidati per il restringimento.

Grazie per i vostri suggerimenti.

Se stai parlando varchare nvarcharpoi no, non c'è penalità per consentire una maggiore lunghezza del campo.

Alcuni avvertimenti da tenere a mente, però:

• Esiste un sovraccarico di 2 byte per riga per campi a lunghezza variabile (per campo). Se hai un campo molto corto, potrebbe avere più senso usare a CHAR. Varchar(2)ad esempio utilizza effettivamente tra 2-4 byte per riga, mentre CHAR(2)usa sempre 2.
• I campi molto lunghi non possono essere indicizzati. La lunghezza massima per tutti i campi in un set di chiavi di indice è di 900 byte.
• Se consenti più dati di quanto ti aspetti, alla fine otterrai risultati imprevisti. Se si consentono 100 caratteri per un nome di strada, ad un certo punto è probabile che altri dati entrino in quel campo senza che l'utente ne sia consapevole (ad esempio l'intero indirizzo). Se le dimensioni fossero adeguate, è probabile che si verifichi un errore in insert.
• Consentire righe molto ampie potrebbe comportare la divisione e la frammentazione della pagina. Se hai una riga più lunga di 8k, dovrai dividerla su più pagine di dati. Molti di questi possono davvero danneggiare le prestazioni. Più stretto in generale è più efficiente.

Se intendi "Esiste una penalità per dichiarare la dimensione del campo maggiore di qualsiasi valore effettivamente memorizzato al suo interno?", Quindi finché viene dichiarato varchar, la risposta è no. Ogni motore SQL DB che conosco memorizza solo il numero di caratteri effettivamente dati nei dati (più un valore di lunghezza). Quindi, se si definisce il campo come varchar (100) ma si memorizzano solo 10 caratteri al suo interno, allora occuperà solo 10 caratteri sul disco (più 2 byte circa per la lunghezza). In caso di dubbio, rendo sistematicamente i miei campi varchar ridicolmente grandi.

Se intendi "Esiste una penalità per la memorizzazione di campi di caratteri lunghi", la risposta è sì. Lo spazio su disco oggi è economico, ma non è gratuito, quindi non vuoi sprecarlo senza motivo. Probabilmente più importante, ci vuole tempo per leggere i dati dal disco, quindi più lunghi sono i campi di dati, più lento diventa il programma. Se il campo è indicizzato, questo può davvero rallentare i tuoi recuperi, poiché ogni lettura dovrà confrontare il valore chiave con questo grande campo lungo.

Tieni presente che se dai all'utente un campo di immissione dati di grandi dimensioni, lo utilizzerà prima o poi.

Detto questo, sbaglierei dal lato troppo grande piuttosto che troppo piccolo. Lo spazio su disco è abbastanza economico da non voler forzare gli utenti a inventare le abbreviazioni al volo perché non possono adattare i dati reali al campo disponibile. Il sistema su cui sto lavorando oggi ha un campo di descrizione del prodotto che è troppo piccolo per molti dei nomi reali dei nostri prodotti, quindi gli utenti devono abbreviare. E ovviamente ogni utente abbrevia in modo diverso, quindi abbiamo venti modi diversi per dire la stessa cosa.

Chiunque sostenga che non vi è alcuna penalità per la dichiarazione di una dimensione del campo più grande di ciò che verrà effettivamente archiviato nella tabella non è corretto. La dimensione effettiva dei dati (oltre al sovraccarico di 2 byte) è ciò che viene effettivamente archiviato, ma è la definizione di colonna che viene utilizzata per determinare la stima fino al piano di esecuzione. Quindi, pur dichiarando un varchar (1000) per memorizzare un valore di 10 caratteri consumerà solo 12 caratteri di spazio su disco, le stime del piano di esecuzione saranno molto meno efficienti e negative distorceranno i risultati, sia per quanto memoria da concedere all'operazione che per se l'operazione può essere eseguita solo in memoria o se richiederà anche spazio sull'unità tempdb. È possibile rendere varchar la colonna (1000), ma il motore non sa che tutti i valori memorizzati sono in realtà inferiori a varchar (10),

Il controllo della lunghezza dei campi è qualcosa che ottieni "gratuitamente", il che significa che non devi usare un CHECKvincolo per fare lo stesso. E non vuoi valori di dati di grandi dimensioni quando, ad esempio, devi caricare i tuoi dati su un altro database che ha limitato lo stesso elemento di dati a 35 caratteri in linea con l'indirizzo standard internazionale.