Terminología de intercalación

Para hacer un uso óptimo de la compatibilidad con idiomas en SQL Server 2005, debería comprender los términos definidos en este tema.

Términos

• Página de códigos
• Intercalación
• Tipo de datos
• Globalización
• Configuración regional
• Orden de lectura
• Criterio de ordenación
• Unicode

Página de códigos

Una página de códigos es un juego ordenado de caracteres en una secuencia de comandos determinada en el que un índice numérico, o un valor de punto de código, está asociado con cada carácter. Una página de códigos de Microsoft se denomina normalmente juego de caracteres o charset. Las páginas de códigos se utilizan para ofrecer compatibilidad con juegos de caracteres y distribuciones de teclado utilizados por distintas configuraciones regionales de Windows.

Temas relacionados:Configurar las páginas de códigos de clientes

Volver al principio

Intercalación

Una intercalación especifica los patrones de bits que representan a cada carácter de un conjunto de datos. Las intercalaciones también determinan las reglas que ordenan y comparan datos. SQL Server 2005 admite almacenamiento de objetos con distintas intercalaciones en una sola base de datos (cada columna de una base de datos de SQL Server puede tener su propia intercalación). En columnas que no sean Unicode, la configuración de intercalación especifica la página de códigos de los datos y, por ende, qué caracteres se pueden representar. Se pueden quitar datos entre columnas Unicode directamente. Los datos entre columnas que no sean Unicode no se pueden quitar directamente y debe convertirlos la página de códigos actual.

El resultado de una instrucción Transact-SQL puede variar cuando la instrucción se ejecuta en el contexto de distintas bases de datos en las que cada una de ellas tenga una configuración de intercalación diferente. Las prácticas recomendadas incluyen el uso de una intercalación normalizada para la organización, siempre que sea posible. El uso de una configuración de intercalación estándar en todos los sistemas de su organización le ayudará a eliminar la necesidad de especificar de manera explícita la intercalación en cada carácter o expresión Unicode. Si tiene que trabajar con objetos que tienen configuraciones de intercalación y de página de códigos distintas, debe codificar sus consultas para que tengan en cuenta las reglas de prioridad de intercalación. Para obtener más información, vea Prioridad de intercalación (Transact-SQL).

Las características de una intercalación distinguen idiomas, mayúsculas de minúsculas, acento, Kana y ancho.

Las intercalaciones de SQL Server 2005 incluyen las siguientes agrupaciones:

• Intercalaciones de Windows
  Las intercalaciones de Windows definen reglas para almacenar los datos de caracteres basadas una configuración regional de Windows asociada. En una intercalación de Windows, la comparación de datos no Unicode se implementa con el mismo algoritmo que la de los datos Unicode. Estas reglas de intercalación básicas de Windows especifican qué alfabeto o idioma se utiliza cuando se aplica un orden de diccionario, y la página de códigos que se utiliza para almacenar los datos de caracteres que no son Unicode. Tanto la ordenación Unicode y como la ordenación no Unicode son compatibles con comparaciones de cadenas de una determinada versión de Windows. Esto proporciona coherencia entre los tipos de datos de SQL Server y también ofrece a los programadores la posibilidad de ordenar cadenas en sus aplicaciones utilizando las mismas reglas utilizadas por SQL Server; es decir, llamando a la función CompareStringW de la API Win32 de Microsoft. Para obtener más información, vea Configuración de intercalación en el programa de instalación.

• Intercalaciones binarias
  Las intercalaciones binarias ordenan datos según la secuencia de los valores codificados definidos por la configuración regional y los tipos de datos. Una intercalación binaria de SQL Server define la configuración regional de idioma y la página de códigos ANSI que se van a utilizar, aplicando un orden binario. Las intercalaciones binarias son útiles, gracias a su relativa simplicidad, para obtener un rendimiento mejorado de las aplicaciones. En tipos de datos no Unicode, las comparaciones de datos dependen de los puntos de código definidos en la página de códigos ANSI. En tipos de datos Unicode, las comparaciones de datos dependen de los puntos de código Unicode. En intercalaciones binarias de tipos de datos Unicode, la configuración regional no se tiene en cuenta a la hora de ordenar los datos. Por ejemplo, Latin_1_General_BIN y Japanese_BIN producen idénticos resultados de orden cuando se utilizan en datos Unicode.

  Las intercalaciones binarias anteriores de SQL Server realizaban una comparación de punto de código a punto de código incompleta para datos Unicode. En dichas intercalaciones binarias de versiones anteriores de SQL Server se comparaba el primer carácter como WCHAR, seguido de una comparación byte a byte. Por razones de compatibilidad con versiones anteriores, la semántica de intercalación binaria no se cambiará.

  Las intercalaciones binarias de esta versión de SQL Server incluyen un nuevo conjunto de intercalaciones de comparación de puntos de código pura. Los clientes pueden elegir migrar a las intercalaciones binarias nuevas para aprovecharse de las comparaciones de puntos de código reales y deberían utilizar las nuevas intercalaciones binarias para el desarrollo de nuevas aplicaciones. El nuevo sufijo BIN2 identifica nombres de intercalación que implementan la nueva semántica de intercalación de punto de código. Además, se ha agregado un nuevo indicador de comparación correspondiente a BIN2 para el nuevo orden binario. Para obtener más información, vea Usar intercalaciones binarias.

• Intercalaciones de SQL Server
  Las intercalaciones de SQL Server proporcionan compatibilidad de orden con versiones anteriores de SQL Server. Las intercalaciones de SQL Server se basan en órdenes de SQL Server heredados para datos que no son Unicode (por ejemplo, tipos de datos char y varchar) definidos por SQL Server. Las reglas de ordenación alfabética de datos no Unicode no son compatibles con ninguna rutina de ordenación suministrada por sistemas operativos Windows, pero la ordenación de datos Unicode es compatible con una versión particular de las reglas de ordenación de Windows. Como las intercalaciones de SQL Server utilizan reglas de comparación diferentes para datos no Unicode y para datos Unicode, puede ver resultados diferentes en las comparaciones de los mismos datos, dependiendo del tipo de datos subyacentes. Para obtener más información, vea Utilizar intercalaciones de SQL.

  [!NOTA] Al actualizar una instancia de SQL Server, se puede especificar la compatibilidad de las intercalaciones de SQL Server con las instancias existentes de SQL Server. Como la intercalación predeterminada de una instancia de SQL Server se define durante la instalación, es importante especificar con cuidado la configuración de intercalación cuando:

  • El código de aplicación depende en cierta forma del comportamiento de intercalaciones anteriores de SQL Server.
  • Se va a utilizar réplica de SQL Server 2005 con instalaciones existentes de SQL Server 6.5 o SQL Server 7.0.
  • Se deben almacenar datos de caracteres que reflejen varios idiomas.

SQL Server 2005 admite configuración de intercalaciones en los siguientes niveles de una instancia de SQL Server 2005:

• Intercalaciones de nivel de servidor
  La intercalación predeterminada de una instancia de SQL Server se establece durante la instalación. La intercalación predeterminada de la instancia se convierte también en la intercalación predeterminada de las bases de datos del sistema: master, model, tempdb, msdb y distribution. Después de asignar una intercalación a un objeto distinto de una columna o base de datos, no puede cambiar la intercalación excepto si elimina y vuelve a crear el objeto. En lugar de cambiar la intercalación predeterminada de una instancia de SQL Server, puede especificar la intercalación al crear una base de datos o una columna de base de datos.

  Para consultar la intercalación de servidor de una instancia de SQL Server, utilice la siguiente función SERVERPROPERTY de Transact-SQL:

  SELECT CONVERT (varchar, SERVERPROPERTY('collation'))
  

  Para consultar todas las intercalaciones disponibles del servidor, utilice la siguiente función integrada de fn_helpcollations():

  SELECT * from ::fn_helpcollations()
  

• Intercalaciones de nivel de base de datos
  Cuando cree una base de datos, puede utilizar la cláusula COLLATE de la instrucción CREATE DATABASE para especificar la intercalación predeterminada de la base de datos. Si no especifica ninguna intercalación durante la creación de la base de datos, se asigna a la base de datos la intercalación predeterminada de la base de datos model. La intercalación predeterminada de la base de datos model es la misma que la intercalación predeterminada de la instancia de SQL Server.

  La intercalación de una base de datos de usuario se puede cambiar con la instrucción ALTER DATABASE de la siguiente forma:

  ALTER DATABASE myDB COLLATE Greek_CS_AI
  

  La intercalación actual de una base de datos se puede recuperar utilizando una instrucción como la siguiente:

  SELECT CONVERT (varchar, DATABASEPROPERTYEX('database_name','collation'))
  

  [!NOTA] La alteración de la intercalación de nivel de base de datos no afecta a las intercalaciones de nivel de usuario, de tabla ni de columna.

• Intercalaciones de nivel de columna
  Cuando cree una tabla, puede especificar intercalaciones para cada columna de cadena de caracteres mediante la cláusula COLLATE de la instrucción CREATE TABLE. Si no especifica ninguna intercalación durante la creación de la tabla, se asigna a la columna la intercalación predeterminada de la base de datos.

  La intercalación de una columna se puede cambiar con la instrucción ALTER TABLE de la siguiente forma:

  ALTER TABLE myTable ALTER COLUMN mycol NVARCHAR(10) COLLATE Greek_CS_AI
  

• Intercalaciones de nivel de expresión
  Las intercalaciones de nivel de expresión se establecen durante la ejecución de una instrucción, y afectan al modo en que se devuelve un conjunto de resultados. Esto permite la ordenación de un resultado de modo que la cláusula ORDER BY pueda ser específica del idioma. Utilice una cláusula COLLATE como la siguiente para implementar intercalaciones de nivel de expresión:

  SELECT name FROM customer ORDER BY name COLLATE Latin1_General_CS_AI
  

Volver al principio

Tipo de datos

El tipo de datos es una definición que especifica un intervalo de valores, las operaciones que se pueden realizar en los valores y el modo en que los valores se almacenan en la memoria del equipo. La definición de tipos de datos permite que SQL Server manipule datos de manera previsible. Los tipos de datos de caracteres no Unicode son char, varchar y text. Los tipos de datos Unicode utilizan la representación de caracteres Unicode y son nchar, nvarchar y ntext. Se recomienda el uso de tipos de datos Unicode en las aplicaciones, especialmente si almacena datos de caracteres que reflejan varios idiomas.

Temas relacionados:Tipos de datos (motor de base de datos), Tipos de datos (Transact-SQL), Tipos de datos de Integration Services

Volver al principio

Globalización

Globalización es el proceso de desarrollo de una aplicación de software con características y diseño de código que tienen en cuenta varios idiomas hablados y configuraciones regionales. El diseño globalizado de aplicaciones contempla varias configuraciones regionales e idiomas compatibles con Unicode para entrada, proceso, muestra y salida de datos.

Temas relacionados:Consideraciones internacionales para SQL Server

Volver al principio

Local

Una configuración regional es un conjunto de información asociado con un lugar o una cultura (el nombre y el identificador del idioma hablado, el alfabeto utilizado para escribir el idioma y convenciones culturales). SQL Server 2005 admite las 135 configuraciones regionales admitidas por Windows XP. Entre ellas hay cinco configuraciones regionales del idioma chino (Hong Kong ZAE RPC, Macao ZAE RPC, República Popular China, Singapur y Taiwán); trece configuraciones regionales del idioma inglés (Australia, Belice, Canadá, Caribe, Irlanda, Jamaica, Nueva Zelanda, Filipinas, Sudáfrica, Trinidad, Reino Unido, Estados Unidos de América y Zimbabue) y seis configuraciones regionales del idioma francés (Bélgica, Canadá, Francia, Luxemburgo, Mónaco y Suiza).

La siguiente tabla ilustra las diferencias entre cuatro configuraciones regionales normales admitidas por Windows.

Configuración regional	Inglés (EE.UU.)	Francés (Francia)	Japonés	Emiratos Árabes Unidos
País/región	Estados Unidos	Francia	Japón	Emiratos Árabes Unidos
Idioma	Inglés	Francés	Japonés	Árabe
Alfabetos escritos	Latín	Latín	Kana, kanji	Árabe
Orden de lectura	De izquierda a derecha	De izquierda a derecha	De izquierda a derecha	De derecha a izquierda
Página de códigos definida por Windows	1252	1252	932	1256
Formato de hora	1:00 pm	13:00	13:00	1:00 p
Calendar	Gregoriano	Gregoriano	Gregoriano (adaptado)	Gregoriano (adaptado)
Tamaño de papel predeterminado	Carta (EE.UU.)	A4	A4	A4
Separador decimal	.	,	.	,
Separador de listas	,	;	,	;
Separador de miles	,	espacio	,	,

Volver al principio

Orden de lectura

El orden de lectura es la dirección general de una secuencia ordenada de texto, en relación con el orden de las palabras, no con el orden de los caracteres escritos. Por ejemplo, si utiliza el árabe como idioma del teclado los nuevos caracteres irán siempre de derecha a izquierda. Cuando el idioma del teclado es el latín, los nuevos caracteres irán de izquierda a derecha.

Volver al principio

Criterio de ordenación

El criterio de ordenación especifica el modo en que se ordenan los valores de datos, algo que afecta a los resultados de la comparación de datos. El orden de los datos se lleva a cabo mediante intercalaciones, y se puede optimizar mediante índices.

Temas relacionados:Estilos de orden de la intercalación de Windows, Índices

Volver al principio

Unicode

Unicode representa los caracteres de un idioma con dos bytes en lugar de con uno, lo que permite la existencia de un único juego de caracteres Unicode para representar casi todos los idiomas escritos del mundo. Unicode fue desarrollado, y es mantenido y promocionado, por Unicode Consortium, una organización del sector informático sin fines lucrativos. Para obtener más información, vea el sitio Web de Unicode Consortium.

Si almacena datos de caracteres que reflejan varios idiomas, utilice siempre tipos de datos Unicode (nchar, nvarchar y ntext) en lugar de tipos de datos que no sean Unicode (char, varchar y text). Con Unicode, obtendrá una mejora considerable en el rendimiento, ya que necesitará menos conversiones de páginas de códigos. Existen importantes limitaciones asociadas con los tipos de datos que no son Unicode, porque un equipo que no sea Unicode estará limitado a utilizar una sola página de códigos. Para evaluar completamente los problemas relacionados con el uso de tipos de datos Unicode y no Unicode, deberá probar su escenario y medir las diferencias de rendimiento en su entorno específico. Como mínimo, normalice la intercalación del sitio, e implemente servidores y clientes Unicode siempre que sea posible.

En la mayoría de los casos, la instancia de SQL Server interactuará con otros servidores y clientes, y la instancia podrá utilizar varios estándares de datos. Los clientes de SQL Server son de dos tipos principales:

• Clientes Unicode que utilizan OLE DB y Conectividad abierta de bases de datos (ODBC) versiones 3.7 o posteriores.
• Clientes no Unicode que utilizan DB-Library y ODBC versiones 3.6 o anteriores.

La siguiente tabla presenta consideraciones para el uso de datos multilingües con varias combinaciones de servidores Unicode y no Unicode.

Servidor	Cliente	Beneficios o limitaciones
Unicode	Unicode	Una configuración ideal porque los datos Unicode se utilizarán en todo el sistema. Este escenario proporciona el mejor rendimiento y la mejor protección contra la corrupción de datos recuperados. Se trata del caso de Microsoft ActiveX Data Objects (ADO), OLE DB y ODBC versiones 3.7 o posteriores.
Unicode	No Unicode	En este escenario, el almacenamiento de datos puede no ser un problema, pero pueden existir limitaciones al mover datos a un equipo cliente. Como mínimo, los datos Unicode deberán convertirse utilizando la página de códigos del cliente no Unicode.
No Unicode	Unicode	No es una configuración ideal para utilizar datos multilingües. No podrá escribir datos Unicode en el servidor no Unicode. Es probable que se produzcan problemas si los datos se envían a servidores externos a la página de códigos del servidor.
No Unicode	No Unicode	Se trata de un escenario muy limitado para datos multilingües. Se verá limitado a utilizar una sola página de códigos. La configuración ideal es un servidor Unicode con clientes Unicode.

Temas relacionados:Conceptos básicos de Unicode

Volver al principio

Vea también

Referencia

Opciones de intercalación y soporte internacional

Ayuda e información

Obtener ayuda sobre SQL Server 2005