Efectos de Unicode en el almacenamiento y el rendimiento
SQL Server 2005 almacena los datos Unicode mediante el esquema de codificación UCS-2. Con este mecanismo, todos los caracteres Unicode se almacenan con 2 bytes.
La diferencia entre el almacenamiento de datos de caracteres en Unicode o de otro modo depende de si los datos que no son Unicode se almacenan mediante conjuntos de caracteres de doble byte. Todos los idiomas excepto los de Asia oriental y el tailandés almacenan los caracteres que no son Unicode en un solo byte. Por lo tanto, el almacenamiento de estos idiomas como Unicode ocupa el doble de espacio que se utiliza si se especifica una página de código que no sea Unicode. Por otro lado, las páginas de código que no son Unicode de muchos otros idiomas asiáticos especifican el almacenamiento de caracteres en conjuntos de caracteres de doble byte (DBCS). Por lo tanto, para estos idiomas casi no hay ninguna diferencia entre el almacenamiento Unicode o no Unicode.
En la tabla siguiente se muestran las páginas de código no Unicode que especifican el almacenamiento de datos de caracteres en conjuntos de caracteres de doble byte.
| Idioma | Página de código |
|---|---|
Chino simplificado |
936 |
Chino tradicional |
950 |
Japonés |
932 |
Coreano |
949 |
El efecto de los datos Unicode en el rendimiento se ve complicado por una serie de factores, entre los que se incluyen los siguientes:
- La diferencia las reglas de ordenación Unicode y no Unicode
- La diferencia entre la ordenación de caracteres de doble byte y de un solo byte
- La conversión de páginas de código entre el cliente y el servidor
SQL Server realiza comparaciones de cadenas de datos no Unicode definidos con una intercalación de Windows mediante reglas de ordenación Unicode. Puesto que estas reglas son muchos más complejas que las reglas de ordenación no Unicode, utilizan más recursos. Por lo tanto, aunque las reglas de ordenación Unicode suelen ser más costosas, por lo general no hay una gran diferencia de rendimiento entre los datos Unicode y los no Unicode definidos con una intercalación de Windows.
El único caso en el que SQL Server utiliza reglas de ordenación no Unicode es en los datos no Unicode que se definen mediante intercalaciones de SQL. Las ordenaciones y los recorridos en este caso suelen ser más rápidos que cuando se aplican las reglas de ordenación Unicode. Las reglas de ordenación Unicode se aplican a todos los datos Unicode definidos mediante una intercalación de Windows o de SQL.
Tiene menor importancia el hecho que la ordenación de grandes cantidades de datos Unicode puede resultar más lenta que la de los datos no Unicode, puesto que se almacenan en doble byte. Por otro lado, la ordenación de caracteres asiáticos en Unicode resulta más rápida que la de datos DBCS asiáticos de una página de código específica, porque los datos DBCS son en realidad una combinación de anchos de un solo byte y dos bytes, mientras que el ancho de los caracteres Unicode es fijo.
Otros problemas de rendimiento vienen determinados principalmente por el problema de conversión del mecanismo de codificación entre una instancia de SQL Server y el cliente. Por lo general, el efecto sobre el rendimiento de la conversión de la página de código cliente/servidor es insignificante. No obstante, es necesario comprender qué ocurre en este nivel.
Las API ODBC versión 3.6 o anteriores y la API DB-Library no reconocen Unicode. En el caso de los clientes que utilizan los métodos de acceso a datos definidos por estas API, se utilizan recursos para convertir de forma implícita los datos Unicode a la página de código del cliente. Asimismo, existe el riesgo de que se dañen datos en el cliente si su página no reconoce determinados caracteres Unicode.
Las versiones posteriores de ODBC, a partir de la versión 2.7 de Microsoft Data Access Components, incluida en SQL Server versión 7.0, OLE DB y ADO son compatibles con Unicode y asumen un mecanismo de codificación UCS-2. Por lo tanto, si la aplicación está habilitada para Unicode, no habrá ningún problema de conversión cuando trabaje únicamente con datos Unicode desde una instancia de SQL Server. Si un cliente utiliza una API habilitada para Unicode, pero el mecanismo de almacenamiento de datos de la instancia de SQL Server no es Unicode, no habrá ningún problema de conversión. Sin embargo, existe el riesgo de que se dañen los datos de las operaciones de inserción o actualización si los puntos de código de algún carácter no se pueden asignar a la página de código de SQL Server.
Prácticas recomendadas para Unicode
La decisión de almacenar datos distintos de DBCS como Unicode suele venir determinada por la preocupación de los efectos en el almacenamiento y por las posibilidades de ordenación, conversión y datos dañados que se pueden dar durante las interacciones del cliente con los datos. La ordenación y conversión pueden afectar al rendimiento según dónde tengan lugar. No obstante, este efecto es insignificante en la mayoría de aplicaciones. Las bases de datos con índices correctamente diseñados tienen pocas posibilidades de verse afectadas. Sin embargo, el hecho de que se dañen datos no sólo afectará a la integridad de una aplicación y una base de datos, sino también a la totalidad de una empresa. Teniendo en cuenta este desequilibrio, el almacenamiento de datos de caracteres en una página de código específica puede resultar interesante si se cumplen todas las condiciones siguientes:
- El mantenimiento del espacio de almacenamiento es un problema debido a limitaciones del hardware. Se realizan ordenaciones frecuentes de grandes cantidades de datos y las pruebas indican que un mecanismo de almacenamiento Unicode afecta gravemente al rendimiento.
- Está seguro de que las páginas de código de todos los clientes que tienen acceso a estos datos coinciden con las suyas y de que esta situación no cambiará de forma inesperada.
La mayoría de las veces, la decisión de almacenar datos de caracteres, incluso los datos no DBCS, en Unicode se debe basar más en las necesidades de la empresa que en el rendimiento. En una economía global apoyada por el rápido crecimiento del tráfico de Internet, cada vez resulta más importante la compatibilidad con los equipos cliente con configuraciones regionales distintas. Asimismo, cada vez es más difícil seleccionar una sola página de código compatible con todos los caracteres que necesitan los usuarios procedentes de todo el mundo.
Vea también
Conceptos
Arquitectura de intercalaciones y páginas de códigos
Tipos de intercalación