SQL Server Collation Choices

Question

He pasado mucho tiempo esta noche tratando de encontrar una guía sobre qué elección de intercalación aplicar en mi instalación de SQL Server 2008 R2, pero casi todo en línea básicamente dice "elija lo que es correcto para usted". " Extremadamente inútil.

Mi contexto es el desarrollo de nuevas aplicaciones. No me preocupa la compatibilidad con versiones anteriores de SQL Server (por ejemplo, < = 2005). Estoy muy interesado en almacenar datos que representen idiomas de todo el mundo, no solo latinos. La poca ayuda que he encontrado en línea sugiere que debería evitar todas las intercalaciones "SQL_". Esto reduce mi elección al uso de una intercalación binaria o "no binaria" basada en la configuración regional de Windows.

Si uso binario, deduzco que debería usar "BIN2". Entonces esta es mi pregunta. ¿Cómo puedo determinar si debo usar BIN2 o simplemente "Latin1_General_100_XX_XX_XX"? Mi sentido araña me dice que BIN2 proporcionará una intercalación que es "menos precisa", pero más genérica para todos los idiomas (¡y rápido!). También sospecho que la intercalación binaria es sensible a mayúsculas y minúsculas, sensible al acento y sensible a kana (¿sí?). Por el contrario, sospecho que la intercalación no binaria funcionaría mejor para los idiomas basados ​​en el latín.

La documentación no es compatible con mis afirmaciones anteriores, estoy haciendo conjeturas. ¡Pero este es el problema! ¿Por qué la documentación en línea es tan delgada que la elección queda en las suposiciones? Incluso el libro "SQL Server 2008 Internals" discutió la variedad de opciones, sin explicar por qué y cuándo se elegiría la intercalación binaria (en comparación con la intercalación de ventanas no binarias). Criminy !!!

Answer 1

La mejor intercalación predeterminada para una base de datos global (por ejemplo, un sitio web) es probablemente Latin1_General_CI_AS. Más importante que la intercalación es asegurarse de que todas las columnas textuales usen el tipo de datos nvarchar.

Answer 2

"SQL Server 2008 Internals" tiene una buena discusión sobre el tema imho.

La compilación binaria es complicada, si tiene la intención de admitir la búsqueda de texto para seres humanos, será mejor que vaya con no binario. Binary es bueno para obtener un poco de rendimiento si ha ajustado todo lo demás (primero la arquitectura) y en casos donde la sensibilidad de mayúsculas y minúsculas y la sensibilidad al acento son un comportamiento deseado, como los hash de contraseñas, por ejemplo. La intercalación binaria es en realidad "más precisa" en el sentido de que no considera textos similares. Sin embargo, los órdenes de clasificación que sacas de allí son buenos para las máquinas.

Hay solo una pequeña diferencia entre las intercalaciones SQL_ * y las ventanas nativas. Si no tiene restricciones de compatibilidad, vaya a los nativos ya que son el camino a seguir afaik.

La clasificación determina el orden de clasificación y la igualdad. Tú eliges, lo que realmente se adapta mejor a tus usuarios. Se entiende que utilizará los tipos Unicode (como nvarchar) para que sus datos sean compatibles con el texto internacional. La intercalación afecta lo que se puede almacenar en una columna no unicode, lo que no le afecta a usted en ese momento.

Lo que realmente importa es que evite mezclar intercalaciones en la cláusula WHERE porque ahí es donde paga la multa al no usar índices. Afaik no hay una recopilación de balas de plata para admitir todos los idiomas. Puede elegir uno para la mayoría de sus usuarios o acceder al soporte de localización con una columna diferente para cada idioma.

Una cosa importante es tener la intercalación del servidor igual que la intercalación de la base de datos. Hará su vida mucho más fácil si planea usar tablas temporales como tablas temporales si se creó con "CREATE TABLE #ttt ..." recoger la intercalación del servidor y se encontraría con conflictos de intercalación que deberá resolver con especificando una intercalación explícita. Esto también tiene un impacto en el rendimiento.

Answer 3

Por favor, no tienen en cuenta mi respuesta tan completa, pero se debe tener en cuenta los siguientes puntos:

• (según lo dicho por #Anthony) Todos los campos de texto deben utilizar nvarchar tipo de datos. Esto le permitirá almacenar cualquier carácter de cualquier idioma, tal como lo define el juego de caracteres UTF-8\unicode. Si no lo haces, no podrás mezclar texto de diferentes orígenes (latino, cirílico, árabe, etc.) en tus tablas.

Dicho esto, la elección de colación afectará principalmente a lo siguiente:

• El orden de clasificación, o las reglas de ordenación que se establezcan entre los caracteres tales como 'e' y 'E' o 'c' y 'ç' (¿deberían considerarse iguales o no?). En algunos casos, las secuencias de clasificación consideran combinaciones de letras específicas, al igual que en húngaro, donde C y CS, o D, DZ y DZS, se consideran de forma independiente.
• La forma en que se analizan los espacios (u otros caracteres que no sean letras): ¿cuál es el orden "alfabético" correcto?

este (espacios son considerados como personajes de primer rango ")?

San Juan 
San Teodoro 
Santa Barbara 

o éste (no se consideran los espacios en el pedido)?

San Juan 
Santa Barbara 
San Teodoro 

• intercalación también impactos en mayúsculas y minúsculas: hacer letras mayúsculas tienen que ser considerado como similar a las letras pequeñas?

Answer 4

Mientras utiliza columnas nvarchar (como debería de datos internacionales mixtos), todos _bin * y * _BIN2 colaciones cumplen la misma comparación binaria/Clasificación basada en los puntos de código Unicode. No importa cuál elijas. Latin1_General_BIN2 parece una opción genérica razonable.

Fuente: http://msdn.microsoft.com/en-us/library/ms143350(v=sql.105).aspx