Efeitos de armazenamento e desempenho do Unicode
SQL Server armazena os dados Unicode usando o esquema de codificação do UCS-2. Com este mecanismo, todos os caracteres Unicode são armazenados usando 2 bytes.
A diferença em armazenar dados de caracteres Unicode e não-Unicode depende se os dados estão armazenados em conjuntos de caracteres de dois bytes ou não. Todos os idiomas que não são do Extremo Oriente e o idioma tailandês armazenam caracteres não-Unicode em bytes simples. Portanto, ao armazenar esses idiomas como Unicode, usa-se duas vezes o espaço usado para especificar uma página de código não-Unicode. Por outro lado, as páginas de código não-Unicode de muitos outros idiomas asiáticos especificam a armazenagem de caracteres em conjuntos de caracteres de dois bytes (DBCS). Assim, para esses idiomas quase não há diferença entre armazenar em Unicode e não-Unicode.
A tabela seguinte mostra páginas de código não-Unicode que especificam os dados de caracteres armazenados em conjuntos de caracteres de dois bytes.
Idioma |
Página de código |
|---|---|
Chinês simplificado |
936 |
Chinês tradicional |
950 |
Japonês |
932 |
Coreano |
949 |
O efeito dos dados Unicode em desempenho é complicado devido a diversos fatores, incluindo os seguintes:
A diferença entre as regras de classificação de Unicode e não-Unicode.
A diferença entre a classificação entre caracteres de dois bytes e caracteres de um byte
Conversão da página de código entre cliente e servidor
O SQL Server executa comparações em cadeia de dados não-Unicode definidos com o agrupamento do Windows usando as regras de classificação de Unicode. Por essas regras serem muito mais complexas do que as regras de classificação de não-Unicode, elas são recursos mais intensivos. Assim, apesar das regras de classificação de Unicode serem, freqüentemente, mais expansivas, em geral há poucas diferenças entre os dados Unicode e os dados não-Unicode definidos com um agrupamento do Windows.
O SQL Server usa as regras de classificação não-Unicode somente quando os dados não-Unicode estão definidos usando o agrupamento SQL. Neste exemplo, as instâncias e os exames são, geralmente, mais rápidos do que quando se aplica as regras de classificação de Unicode. As regras de classificação de Unicode aplicam-se a todos os dados Unicode definidos usando tanto o agrupamento do Windows quanto o agrupamento do SQL.
Em segundo plano, classificar diversos dados Unicode pode ser mais lento do que classificar dados não-Unicode, pois os dados são armazenados e conjuntos de dois bytes. Por outro lado, classificar caracteres asiáticos em Unicode é mais rápido do que classificar dados DBCS asiáticos em uma página de código específica, pois os dados DBCS são, na verdade, uma mistura de larguras de um byte e de dois bytes, enquanto que os caracteres Unicode têm uma largura fixa.
Outros problemas de desempenho decorrem, principalmente, de problemas de conversão do mecanismo de codificação entre uma instância do SQL Server e o cliente. Geralmente, os efeitos no desempenho da conversão da página de código cliente/servidor não são muito importantes. Entretanto, é preciso entender o que está ocorrendo nesta camada.
A ODBC API versão 3.6 ou anterior e a DB-Library API não reconhecem o Unicode. Para os clientes que usam os métodos de acesso de dados definidos por essas APIs, são usados recursos para converter implicitamente os dados Unicode à página de código do cliente. Há, também, o risco de ocorrer uma corrupção de dados do lado do cliente quando a página de código do cliente não reconhecer determinados caracteres Unicode.
Versões anteriores do ODBC, começando com o Microsoft Data Access Components (MDAC) versão 2.7 incluído no SQL Server versão 7.0, o OLE DB e o ADO são Unicode e aceitam um mecanismo de codificação UCS-2. Portanto, se a aplicação for habilitada para Unicode, não haverá problemas de conversão ao trabalhar estritamente com pontos de código de dados Unicode de uma instância do SQL Server. Caso o cliente esteja usando uma API habilitada para Unicode, mas o mecanismo de armazenamento de dados na instância do SQL Server não for Unicode, não haverá problemas de conversão. No entanto, há um risco de que qualquer dado inserido ou operação de atualização seja corrompida caso algum caractere não possa ser mapeado para a página de código do SQL Server.
Práticas recomendadas de Unicode
A decisão de armazenar ou não dados não-DBCS comoUnicode é, de maneira geral, determinada pelo reconhecimento dos efeitos no armazenamento e pela quantidade de instâncias, conversões e possíveis corrupções de dados que podem ocorrer durante as interações do cliente com os dados. A classificação e conversão podem afetar o desempenho, dependendo de onde ocorrerem. Porém, para a maioria dos aplicativos o efeito é insignificante. É pouco provável que bancos de dados com índices bem projetados sejam afetados. No entanto, a corrupção de dados afetará não apenas a integridade de um aplicativo e base de dados, mas também a empresa como um todo. Considerando este “trade-off”, armazenar dados de caracteres em uma página de código específica só fará sentido se existirem as seguintes condições:
A preservação do espaço de armazenamento é um problema devido às limitações do hardware. Ou, você está freqüentemente realizando classificações de muitos dados e os testes indicam que um mecanismo de armazenamento Unicode está afetando o desempenho.
Você tem certeza de que as páginas de código de todos os clientes que têm acesso a esses dados correspondem aos seus e esta situação não se alterará de forma inesperada.
Na maior parte do tempo, a decisão de armazenar dados de caracteres, mesmo os dados não-DBCS, em Unicode devem ter como base as necessidades da empresa em vez do desempenho. Em uma economia global incentivada pelo rápido crescimento do tráfego da Internet, está se tornando cada vez mais importante o suporte aos computadores dos clientes que estão sendo executados em diferentes localidades. Além disso, está se tornando muito difícil escolher uma única página de código que oferece suporte a todos os caracteres solicitados por um público mundial.