Sto progettando uno schema di database in questo momento e immagino che per essere sicuro dovrei usare nvarchar per i tipi di dati della mia colonna testuale (per il supporto Unicode). Anche se non mi aspetto testo non inglese, immagino che sarebbe meglio supportarlo dall'inizio per ogni evenienza.C'è una ragione per cui non dovrei usare NVARCHAR in Sql Server?
C'è qualche motivo per cui dovrei rimanere con varchar normale? Prestazione?
Sì, prestazioni, dimensioni. nvarchar richiede più byte, penso che sia doppio (correggimi se sbaglio) e questo è dovuto al supporto Unicode. Quindi, se non hai bisogno del supporto Unicode, vai con varchar regolare.
Nel mondo i18n di oggi, nvarchar ha molto senso. varchar potrebbe avere senso per i dati che sono specificati per non essere unicode (forse si hanno alcuni campi di sistema che sono richiesti per essere ASCII).
userei nvarchar per impostazione predefinita per le cose come i nomi, descrizioni, indirizzi, ecc
varchar è più piccolo, quindi non ci sono forse qualche risparmio IO con varchar oltre nvarchar (ma nota che il codice-pagina diventa un problema più grande troppo).
Inoltre, si veda questa domanda: VARCHAR vs NVARCHAR performance.
Personalmente, dico attengo a varchar (come ho risposto a questa discussione). C'è un overhead delle prestazioni non banali.
Utilizziamo VARCHAR per quasi tutto e NVARCHAR solo molto occasionalmente.
Codici Prodotto non hanno bisogno nvarchar - non permettiamo qualcosa di diverso da AZ, 0-9 e "_" in loro ...
Il suo doppio dello spazio di archiviazione, ma anche solo la metà della le voci per pagina indice (e per pagina dati) e metà della memoria cache sono "sprecate", più cicli CPU per confrontare i dati e così via.
IME gli accenti stranieri comunemente usati funzionano solo a Varchar (cioè LATIN-1). Non abbiamo intenzione di creare set di caratteri alternativi cinesi o di altro tipo, e quando saremo in grado di gestire quel set di caratteri utilizzando NVarchar dal primo giorno sarà l'ultima delle nostre preoccupazioni: allineamento del testo da destra a sinistra o verticale ?? :(
E se hai permesso a NVarchar, per esempio, un nome, come hai intenzione di digitare il charcater esteso dalla tua tastiera? E se importi i dati (quindi è già NVarchar) come stai andando a essere in grado di cercare quel cliente usando la tua tastiera QWERTY standard.Molti e molti sono coinvolti con l'internazionalizzazione di un'applicazione, quindi il mio punto di vista è che non ha senso "consentirlo usando NVarchar".
Ma ci sono ancora molti posti andare ad avere NVarchar ... e la maggior parte delle colonne hanno anche 50 caratteri di larghezza .... devono sapere qualcosa sulla crescita della popolazione e piani di espansione per i codici postali che io non !!
Come già detto, il il trade off è a prova di futuro rispetto alla performance. Nella mia esperienza, SQL Server funziona abbastanza bene con limiti di CPU e memoria inferiori, ma gli diamo un I/O del disco lento e può davvero fare il chug.
Se non si hanno piani per set di caratteri a doppio byte (cioè caratteri cinesi), attenersi a VARCHAR (MAX).
In generale; Inizia con il tipo di dati più costoso che presenta i vincoli minimi. Mettilo in produzione. Se la prestazione inizia a essere un problema, scopri cosa viene effettivamente memorizzato in quelle colonne nvarchar. C'è qualche personaggio lì dentro che non si adatta a varchar? Altrimenti, passa a varchar. Non provare a pre-ottimizzare prima di sapere dove si trova il dolore. La mia ipotesi è che la scelta tra nvarchar/varchar non sia ciò che rallenta la tua applicazione nel futuro prevedibile. Ci saranno altre parti dell'applicazione dove la regolazione delle prestazioni ti darà molto più valore per i dollari.
Aggiungerei la versione di SQL Server alla domanda, potrebbe fare la differenza? – Ash
Attualmente sto utilizzando SQL Server 2005, ma alla fine stiamo cercando di passare al 2008. – mmcdole