Perché esiste ancora un tipo di dati varchar?

Molti dei miei database hanno campi definiti come varchars. Questo non è stato un grosso problema da quando vivo e lavoro in America (dove l'unica lingua che esiste è "americana". Ahem )

Dopo aver lavorato con i database per circa 5 anni, ho scoperto che alla fine ho riscontrato problemi con la natura limitata del campo varchar e devo modificare i miei campi per archiviare i dati come nvarchars. Dopo aver dovuto effettuare un altro aggiornamento in una tabella, convertendo un campo varchar in un nvarchar, ho pensato: perché lo stiamo ancora facendo in questo modo? Da tempo ho preso la decisione mentale di definire tutti i miei nuovi campi di testo in nvarchar, anziché varchar, che è ciò che ho imparato a fare dai miei libri di testo quando ero a scuola 10 anni fa.

È il 2011 e l'anno scorso è stata rilasciata una nuova versione di SQL Server. Perché continuiamo a supportare un tipo di dati varchar quando possiamo / dovremmo invece utilizzare nvarchar?

So che si sostiene spesso che i nvarchar sono "due volte più grandi" dei varchar, quindi l'utilizzo dello spazio di archiviazione potrebbe essere un argomento per mantenere i varcar.

Tuttavia, gli utenti di oggi potrebbero definire i loro nvarchars per archiviare i dati come UTF-8 anziché come UTF-16 predefinito se vogliono risparmiare spazio di archiviazione. Ciò consentirebbe la codifica a 8 bit se ciò è principalmente desiderabile, garantendo al contempo che il raro carattere da 2-8 byte che viene inserito nel loro DB non romperà nulla.

Mi sto perdendo qualcosa? C'è una buona ragione per cui questo non è cambiato negli ultimi 15-20 anni?

1. il lavoro varchar è abbastanza buono per molte lingue dell'Europa occidentale (norvegese, danese, tedesco, francese, olandese ecc.) soggetto ad alcuni problemi di confronto

2. Vedi questo su SO varchar vs prestazioni nvarchar nvarchar ha gravi conseguenze sulle prestazioni

3. Questo è banale rispetto al trattare con le date MDY vs DMY

Oltre alle risposte relative agli standard e alla compatibilità, è necessario tenere presente le prestazioni. Mentre lo spazio su disco è prontamente accettato come economico, i DBA / gli sviluppatori spesso ignorano il fatto che le prestazioni della query sono a volte direttamente correlate alla dimensione di riga / pagina di una tabella. L'uso NVARCHARpiuttosto che VARCHAR(quando non necessario) raddoppierà effettivamente le dimensioni della riga per i campi del personaggio. Se hai, diciamo, 5 o 10 campi di lunghezza 50, stai parlando di aggiungere potenzialmente altri 500 byte per riga. Se si dispone di una tabella ampia, questo potrebbe spingere ogni riga in più pagine e avere un effetto negativo sulle prestazioni.

Molte organizzazioni hanno ancora una vasta base installata di applicazioni, interfacce, piattaforme e strumenti che assumono caratteri a byte singolo. I database raramente vivono isolati - fanno parte di un ecosistema IT. Se hai migliaia di componenti e milioni di righe di codice dipendenti da caratteri a byte singolo, allora avresti bisogno di un buon motivo per investire il tempo e il denaro necessari per passare all'unicode. I cambiamenti su tale scala potrebbero richiedere anni per essere completati. In alcuni punti Unicode è ancora relativamente nuovo, raro o non completamente supportato.

VARCHAR e NVARCHAR fanno entrambi parte dello standard ISO SQL. Rimuovere o deprecare il supporto VARCHAR in SQL Server sarebbe un passo indietro in termini di compatibilità e portabilità.

In alternativa, gli utenti di oggi potrebbero definire i propri nvarchar per archiviare i dati come UTF-8 anziché come UTF-16 predefinito se desiderano risparmiare spazio di archiviazione.

Questo è esattamente ciò che fa la maggior parte dei database open source VARCHAR.

• MySQL fornisce utf8e ucs2"collation".
• SQLite offre una scelta tra UTF-8 (impostazione predefinita) e UTF-16.
• PostgreSQL supporta UTF-8 (ma non UTF-16).

Non è necessario disporre di due tipi di stringa separati.

Microsoft è la strana fuori con la sua vista che le stringhe a 8 bit sono per codifiche legacy e Unicode = UTF-16. Che è probabilmente correlato all'API di Windows stessa chare in wchar_tquesto modo.

Perché alcuni di noi costruiscono applicazioni più leggere e più piccole su hardware meno all'avanguardia, che non necessita di funzionalità Unicode. Forse dovremo cambiarlo in seguito, ma per ora, semplicemente non ne abbiamo bisogno. Mi piacciono le mie stringhe che occupano metà dello spazio che altrimenti avrebbero sotto NVARCHAR.