SQL Server Intercalaciones (Collation)

19:14 3 Comments

Está palabra tan enrevesada es la empleada por Microsoft para definir como se ordenan y comparan las cadenas en los diferentes idiomas. Este punto, por el que se suele pasar muy por encima, es muy importante si se pretende usar SQL Server como backend en una aplicación con soporte para todos los idiomas (al menos en la información que se guarda como es nuestro caso).

El saber que palabra es igual a otra, o cual va antes que otra (alfabéticamente) puede parecer una cosa sin importancia y bastante trivial, en nuestro caso puede ser, pero en el resto de los idiomas no es así. Por ejemplo el Japonés emplea tres alfabetos diferentes, y tiene unas reglas bastante complejas para determinar que carácter va antes y cual después. Es más, inclusive dentro de un idioma como el nuestro existen diferentes criterios para ordenar como puede ser que la combinación de letras “ch” se coloque después de la letra c.

Las intercalaciones permiten definir el idioma, así como una serie de criterios adicionales que se aplican a la hora de diferenciar y ordenar diferentes caracteres. En SQL Server 2005 los idiomas soportados son los mismo que se soportan en los sistemas operativos Windows. Aparte del idioma entre los otros criterios que pueden especificarse son:
  • Permite diferenciar entre mayúsculas y minúsculas (CS Case Sensitive – CI Case Insensitive).
  • Permite diferenciar entre una misma letra acentuada o sin acentuar. (AS Accent Sensitive – AI Accent Insensitive).
  • Permite diferenciar entre las sílabas japonesas katakana e hiragana (KS Kana Sensitive – KI Kana Insensitive).
  • Permite distinguir la representación lógica de los caracteres para poder compararlos como iguales o diferentes desde su ancho (byte), sin importar que sean el mismo carácter (WS Width Sensitive – WI Width Insensitive).

La intercalación puede definirse a diferentes niveles según nos interese en cada caso. Puede definirse a nivel de servidor de BD, a nivel de la BD, a nivel del campo de texto dentro de la tabla o nivel de la consulta. Al margen del primer caso que es para tener una política general para todas ellas, las otras se aplicarían una u otra según nuestras necesidades:
  • Si se aplica a nivel de BD no solamente los datos tendrán en cuenta estos criterios sino los nombres de tablas, campos,..
  • Si se aplica a en los campos de texto dentro de las tablas lo podríamos hacer o para todos los datos o sólo para algunos, pero en cualquier caso los nombre de los elementos de la BD no se verían afectados.
  • Si se aplica en las consultas, ese criterio sólo se aplicaría en esa consulta concreta, puede ser interesante para permitir hacer búsquedas al usuario sin tener que preocuparse de mayúsculas, acentos, etc, inclusive que el mismo lo defina en el momento de hacer la consulta (opciones de la búsqueda).
En cualquiera de los casos COLLATE seguido de la intercalación que se quiera utilizar.

3 comentarios:

Anónimo dijo...

Como dices, se suele pasar por encima de este asunto, pero eso lo hacen quienes no han descubierto el placer de tener que desinstalar y reinstalar SQL Server por culpa de este minúsculo detalle.

Un ejemplo: http://support.microsoft.com/kb/832814/en

To resolve this issue, use case-insensitive collation in SQL Server. The collation for SQL Server 2000 is configured when SQL Server is installed. To resolve this issue, remove, and then reinstall SQL Server with case-insensitive collation.

¡Qué divertido! :'(

Anónimo dijo...

Como le hago para saber cual es la Intercalación en SQL 7.0

Gracias por dar detalle de las intercalaciones.