Archiviazione di dati Unicode ed effetti sulle prestazioni
SQL Server archivia i dati Unicode utilizzando lo schema di codifica UCS-2, in base al quale tutti i caratteri Unicode vengono archiviati utilizzando 2 byte.
Archiviare dati di tipo carattere in formato Unicode è diverso da archiviarli in formato non Unicode solo se i dati non Unicode non vengono archiviati mediante set di caratteri a byte doppio (DBCS). Tutte le lingue, compreso il tailandese ed escluse le lingue dell'Asia orientale, archiviano i caratteri non Unicode in byte singoli. Archiviare queste lingue in formato Unicode, pertanto, richiede il doppio dello spazio che sarebbe necessario specificando una tabella codici non Unicode. D'altra parte, le tabelle codici non Unicode di molte lingue dell'Asia specificano l'archiviazione dei caratteri in formato DBCS (Double-Byte Character Set). Per queste lingue dunque non esiste quasi differenza fra l'archiviazione in formato Unicode e in formato non Unicode.
Nella tabella seguente vengono illustrate le tabelle codici non Unicode che specificano l'archiviazione dei dati di tipo carattere in formato DBCS (Double-Byte Character Set).
Lingua |
Tabella codici |
|---|---|
Cinese semplificato |
936 |
Cinese tradizionale |
950 |
Giapponese |
932 |
Coreano |
949 |
L'impatto dei dati Unicode sulle prestazioni è complicato da numerosi fattori, fra i quali quelli esposti di seguito:
La differenza fra le regole di ordinamento Unicode e non Unicode
La differenza fra l'ordinamento dei caratteri a due byte e a un byte
La conversione delle tabelle codici fra client e server
SQL Server esegue confronti di stringhe dei dati non Unicode definiti mediante le regole di confronto di Windows utilizzando le regole di ordinamento Unicode. Poiché queste regole sono molto più complesse rispetto alle regole di ordinamento non Unicode, richiedono un elevato utilizzo di risorse. Pertanto, sebbene le regole di ordinamento Unicode siano spesso più dispendiose in termini di risorse, esiste in genere poca differenza di prestazioni fra i dati Unicode e i dati non Unicode definiti con le regole di confronto di Windows.
L'unico caso in cui SQL Server utilizza regole di ordinamento non Unicode è per i dati non Unicode definiti utilizzando le regole di confronto SQL. Ordinamenti e scansioni in tal caso sono in genere più veloci rispetto a quando vengono applicate le regole di ordinamento Unicode. Le regole di ordinamento Unicode si applicano a tutti i dati Unicode, definiti utilizzando le regole di confronto di Windows o le regole di confronto SQL.
Di importanza secondaria è il fatto che l'ordinamento di grandi quantità di dati Unicode può richiedere più tempo rispetto ai dati non Unicode, perché i dati sono archiviati in due byte. D'altra parte, ordinare caratteri asiatici in formato Unicode è più veloce che ordinare dati DBCS asiatici in una tabella codici specifica, perché i dati DBCS sono in effetti rappresentati sia da caratteri di 1 byte che da caratteri da 2 byte, mentre i caratteri Unicode sono a larghezza fissa.
Altri problemi di prestazioni sono principalmente determinati dalla conversione del meccanismo di codifica fra un'istanza di SQL Server e il client. Gli effetti della conversione della tabella codici fra client e server sono normalmente irrilevanti, ma è necessario comprendere quanto accade a questo livello.
L'API ODBC versione 3.6 o precedenti e l'API DB-Library non riconoscono il formato Unicode. Per i client che utilizzano metodi di accesso ai dati definiti da queste API, vengono utilizzate risorse per la conversione implicita dei dati Unicode nella tabella codici del client. Esiste inoltre un rischio di danneggiamento dei dati dal lato client quando la tabella codici del client non riconosce alcuni caratteri Unicode.
Le versioni successive di ODBC, a partire da Microsoft Data Access Components versione 2.7 che era incluso in SQL Server versione 7.0, OLE DB e ADO sono compatibili con Unicode e presuppongono un meccanismo di codifica UCS-2. Se l'applicazione è abilitata per Unicode, pertanto, non esistono problemi di conversione quando si lavora esclusivamente con dati Unicode da un'istanza di SQL Server. Se un client utilizza un'API abilitata per Unicode, ma il meccanismo di archiviazione dei dati nell'istanza di SQL Server non è Unicode, non si verificano problemi di conversione. Esiste invece il rischio di errori nelle operazioni di inserimento o aggiornamento di dati se non è possibile mappare i punti di codice di qualche carattere alla tabella codici di SQL Server.
Procedure consigliate per il formato Unicode
La decisione di archiviare o meno dati non DBCS in formato Unicode è normalmente determinata dalla consapevolezza degli effetti sull'archiviazione e dalle probabilità di danneggiamento dei dati e di esecuzione di operazioni di ordinamento e conversione durante l'interazione del client con i dati. Ordinamento e conversione possono influire sulle prestazioni, in base al punto in cui vengono eseguite. L'effetto è irrilevante per la maggior parte delle applicazioni. I database con indici ben progettati, in particolare, sono particolarmente poco vulnerabili. Il danneggiamento dei dati tuttavia ha effetto non solo sull'integrità di un'applicazione e di un database, ma sull'intera attività. Archiviare i dati di tipo carattere in una tabella codici specifica può avere senso solo se vengono soddisfatte entrambe le condizioni seguenti:
È necessario conservare spazio di archiviazione a causa di limitazioni hardware. Oppure, si eseguono frequenti ordinamenti di dati e le verifiche indicano che un meccanismo di archiviazione Unicode influisce molto negativamente sulle prestazioni.
Si è sicuri che le tabelle codici di tutti i client che accedono ai dati corrispondono a quelle in uso e che questa situazione non cambierà improvvisamente.
Nella maggior parte dei casi la decisione di archiviare dati di tipo carattere, anche non DBCS, in formato Unicode, deve essere basata non sulle prestazioni bensì sulle esigenze dell'azienda. In un'economia globale incoraggiata dalla rapida crescita del traffico su Internet, il supporto di computer client con impostazioni locali diverse è sempre più importante. In più, sta diventando sempre più difficile scegliere un'unica tabella codici che supporti tutti i caratteri necessari per gli utenti di tutto il mondo.