TL; DR
No existe una vista "independiente del vendedor" de las intercalaciones, ni siquiera una "versión independiente", ya que sus implementaciones, incluidos los aspectos que pueden volverse insensibles y sus convenciones de denominación, son específicas del proveedor y cambian con el tiempo .
Aquí hay un resumen de lo que he encontrado, y los detalles están en la sección más larga debajo de la línea:
RDBMS Naming- Combinations Case-Sensitive and
convention of options? Accent-Insensitive support?
------- ------------ ------------- -----
SQL Server _CS, _AI, etc Yes Latin1_General_100_CS_AI
DB2 _E{x}, _S{y}, etc Yes CLDR181_EO_S1
PostgreSQL locale: en_US N/A unaccent(), not via Collation
MySQL _cs, maybe _ai No No: _cs implies _as & _ci implies _ai
Yes? Create your own Collation :-)
Oracle only _CI & _AI No No: _AI always implies _CI
SAP ASE arbitrary: turdict N/A No: "AI" always implies "CI"
Informix locale.codepage N/A No: no "AI" via Collations
Como se puede ver en el gráfico, dos de los siete RDBMS hacer de soporte de forma nativa "entre mayúsculas y minúsculas y las operaciones de Accent-insensibles" a través de colaciones, aunque tienen diferentes convenciones de nombres (y varias otras diferencias funcionales).
Un RDBMS, PostgreSQL, no admite de forma nativa esta combinación, pero aún puede lograrlo quitando los acentos con la función de unaccent()complemento.
Los últimos cuatro RDBMS, dos de los cuales tienen una convención de nomenclatura similar para las opciones, ni admiten de forma nativa esta combinación ni parece haber un medio para lograr esto sin escribir su propia función para eliminar los acentos / signos diacríticos. MySQL permite crear sus propias intercalaciones, pero eso requiere que luego lo agregue al control de origen y lo incorpore a su proceso de prueba e implementación para que pueda aplicarse a todos los servidores en todos los entornos (pero sigue siendo una opción muy interesante y flexible) . SAP ASE menciona que SAP puede suministrar órdenes de clasificación Unicode adicionales, pero no menciona lo que podrían estar dispuestos a suministrar.
Con respecto a:
¿Hay una buena razón para esto o el mío es simplemente un caso de uso raro?
Puedo decir que al hacer la investigación para esta respuesta me encontré con muchas instancias de personas que desearían mayúsculas y minúsculas para MySQL, pero pocas, si es que las hay, que piden la combinación deseada.
Quería una condición de búsqueda para utilizar una intercalación entre mayúsculas y minúsculas pero sin acento, pero no pude encontrar una.
...
esta pregunta es independiente del vendedor / versión
No tuvo éxito en su búsqueda porque realmente no tiene sentido buscar un RDBMS basado en una especificación de clasificación. Así no es cómo funcionan las intercalaciones. Y si bien desea abordar esto como un proveedor independiente, la realidad es que las intercalaciones, al menos la parte con la que interactuamos, son muy específicas del proveedor y no siempre se ajustan al esquema en el que estaba buscando .
La comparación y clasificación de cadenas es muy compleja, y hay diferentes formas de realizar estas reglas. Un método es tener asignaciones que tengan en cuenta una o más reglas. Por lo tanto, las cuatro combinaciones de Sensible e Insensible para mayúsculas y minúsculas equivaldrían a cuatro asignaciones separadas. Por ejemplo, viste esto en esa página de MSDN para SQL Server Collation Name . Si se desplaza hacia abajo, verá que la columna izquierda del gráfico es Sort Order ID. Cada intercalación tiene una ID diferente: SQL_Latin1_General_Cp1_CI_AS= 52 mientrasSQL_Latin1_General_Cp1_CS_AS = 51, a pesar de que la única diferencia está en la distinción entre mayúsculas y minúsculas.
O bien, puede basarse en reglas, como lo que ofrece Unicode a través del Algoritmo de clasificación Unicode (UCA). En este enfoque, a cada personaje se le da, por defecto, uno o más pesos. Luego, cada cultura / localidad tiene la opción de anular cualquiera de esos pesos, o eliminar reglas o agregar reglas. El algoritmo tiene en cuenta las reglas específicas de la configuración regional y, a continuación, potencialmente manipula esos pesos en función de las opciones elegidas (sensibilidad, qué caso es lo primero cuando se hacen tipos de mayúsculas y minúsculas, etc.). Esta es una de las razones por las que la ordenación Unicode es un poco más lenta que la ordenación no Unicode.
Para tener una idea de cuántas opciones hay realmente (es decir, la complejidad real), consulte esta demostración del proyecto ICU (International Components for Unicode):
Demostración de colación de UCI
Hay 8 opciones separadas para especificar, y algunos de ellos son representadas en múltiples elementos de la especificación nombre de intercalación que usted está pensando (por ejemplo CS, CI, AS, AI, etc). Dada la cantidad de variaciones que existen, el uso del enfoque de archivo de mapeo donde cada combinación tiene su propia ID daría como resultado muchos miles de archivos. Muchos de esos archivos tendrían que actualizarse cada vez que haya cambios en esos idiomas en particular, o cuando se encuentren errores. Esta es probablemente la razón por la que solo hay 75 de esos tipos de intercalaciones en SQL Server 2012 (es decir, aquellos con nombres que comienzan con SQL_). Por lo tanto, no hay combinación para_CS_AI .
¿Y la razón por la que no pudo encontrar esa combinación para las intercalaciones basadas en UCA? Bueno, hay 3810 colaciones en SQL Server 2012 que no comienzan SQL_, por lo que 3885 colaciones en total. Esa lista parece ser demasiado larga para enumerarse por completo en una página web. Pero esto no explica completamente por qué no pudo encontrar esta combinación para otros proveedores.
Más allá de lo que ya se ha mencionado (es decir, demasiadas combinaciones para implementar y demasiadas implementaciones para enumerar), aún debe lidiar con implementaciones específicas del proveedor. Significado: no todos los proveedores permiten adaptar todas esas opciones, y no existe una convención de nomenclatura estándar para las Colaciones en primer lugar. Además, no todos los proveedores ven las opciones de clasificación como parte de la Clasificación: las clasificaciones PostgreSQL son pedidos predeterminados para la configuración regional elegida, y debe usarlas ILIKEpara obtener una comparación que no distinga entre mayúsculas y minúsculas. Consulte a continuación la información específica del proveedor.
Servidor SQL (Microsoft)
La distinción entre lo que está viendo en esas dos páginas de documentación de MSDN y la consulta proporcionada por @MartinSmith en un comentario sobre la pregunta (ligeramente revisada a continuación):
SELECT *
FROM sys.fn_helpcollations()
WHERE [name] LIKE '%[_]CS[_]AI%';
es que esas dos páginas de MSDN se refieren específicamente a las intercalaciones de SQL Server muy obsoletas, mientras que las intercalaciones que aparecen como resultado de esa consulta (888 de ellas a partir de SQL Server 2012, SP3) son intercalaciones de Windows.
A partir de SQL Server 2000, las antiguas intercalaciones de SQL Server (creadas antes de que SQL Server pueda aprovechar las intercalaciones de Windows) están en desuso y no se actualizan con nuevas reglas o funcionalidades. Por ejemplo, a partir de SQL Server 2012, se agregó un conjunto de intercalaciones que admiten el manejo adecuado de las funciones integradas para los caracteres suplementarios (es decir, los caracteres UTF-16 restantes más allá de los 65.536 caracteres "base" inicialmente definidos en UCS-2 ) Estas nuevas colaciones terminan en _SC(como en S caracteres complementarios C ).
Es mejor no usar las intercalaciones de SQL Server, aquellas con nombres que comienzan con SQL_. Por lo tanto, tiene acceso a muchas Colaciones que admiten la combinación de opciones que está buscando (es decir, mayúsculas y minúsculas). Siempre que esté disponible, también es mejor usar un extremo _SCsiempre que tenga todas las otras opciones que desee.
Si bien SQL Server usa la _CS_AIconvención de nomenclatura, no hay una lista de todas las colaciones de Windows 3810 (a partir de SQL Server 2012). Solo existe la página Nombre de clasificación de Windows que enumera todas las configuraciones regionales y versiones, y cómo funciona la convención de nomenclatura, pero eso es todo.
SQL Server también admite alternar tanto el ancho como la sensibilidad de Kana.
MySQL (comprado por Oracle)
La versión de MySQL 5.7, documentación estados que soporta el _ai, _as, _ci, y _cssufijos (y _binpor la totalidad), sino que también establece lo siguiente:
Para los nombres de colación no binarios que no especifican la sensibilidad de acento, está determinada por la mayúscula y minúscula. Es decir, si un nombre de cotejo no contiene _aio _as, _cien el nombre implica _aiy _csen el nombre implica _as.
Por ejemplo, latin1_general_cies insensible a mayúsculas y minúsculas (y acento insensible, implícitamente), distingue latin1_general_csmayúsculas de minúsculas (y acento sensible, implícitamente)
Esto ciertamente implica que es posible tener una latin1_general_cs_aiIntercalación. Sin embargo, el servidor MySQL 5.5.50 que tengo acceso a no tiene ningún colaciones con más de un sufijo, y el único que veo sufijos son: _cs, _ciy _binal otro lado de la colación por 198 del total. He utilizado el COTEJO MOSTRAR comando para enumerarlos.
Entonces, si bien parece que MySQL usa una convención de nomenclatura similar (al menos en lo que respecta a esas dos opciones), no puedo encontrar una clasificación que coincida con lo que está buscando. Sin embargo, podría ser posible quitar los acentos (y otros signos diacríticos) y usar una _csintercalación para obtener lo que desea (de forma similar a cómo lo haría en PostgreSQL, consulte a continuación). Pero no estoy seguro de esta opción y no tengo tiempo en este momento para investigar más.
O bien , podría crear su propia intercalación para hacer exactamente lo que desea. A diferencia de los otros RDBMS, MySQL parece simplificar la adición de sus propias intercalaciones, en cuyo caso usted tiene el control total sobre la ponderación de cada carácter. Consulte Agregar una intercalación simple a un conjunto de caracteres de 8 bits y Agregar una intercalación UCA a un conjunto de caracteres Unicode para obtener más detalles.
Para obtener más información sobre cómo MySQL maneja los diferentes tipos de intercalaciones, consulte su página Tipos de implementación de intercalaciones .
PostgreSQL
Las intercalaciones en PostgreSQL parecen ser mucho menos flexibles. Sólo se especifica la cultura / locale: en_US, de_DE, etc Por favor, vea su página de documentación para la intercalación Soporte para más detalles. Por lo tanto, de manera predeterminada, obtiene las anulaciones específicas de la cultura, pero las intercalaciones son sensibles a todo (que, por cierto, no es lo mismo que una intercalación "binaria").
Puede usar ILIKE (sección 9.7.1) para obtener insensibilidad a mayúsculas y minúsculas, pero no tienen un operador similar para la sensibilidad del acento. Sin embargo, descubrí que tienen una función poco acertada que se puede usar para quitar los acentos y otras marcas diacríticas. Tenga en cuenta que esta función es un Módulo suministrado adicional y, por lo tanto, no está necesariamente presente en ningún servidor PostgreSQL en particular para usar. La documentación vinculada más recientemente establece:
Al compilar desde la distribución fuente, estos componentes no se compilan automáticamente, a menos que construya el objetivo "mundial"
...
Si está utilizando una versión preempaquetada de PostgreSQL, estos módulos generalmente están disponibles como un subpaquete separado, como postgresql-contrib.
Consulte esa documentación para obtener instrucciones sobre cómo obtener esa función si no la tiene y la quiere.
También se puede encontrar más información en la siguiente respuesta de desbordamiento de pila:
¿PostgreSQL admite colaciones "insensibles al acento"?
DB2 (IBM)
Similar a Microsoft SQL Server, DB2 tiene dos tipos de intercalaciones:
Las intercalaciones "sistema", que se especifican utilizando el siguiente formato: SYSTEM_{codepage}_[optional-territory]. Estos no son muy flexibles y no parecen admitir la sensibilidad de adaptación a mayúsculas, acentos ni nada. Puede encontrar la lista de intercalaciones compatibles aquí: códigos de territorio y páginas de códigos compatibles
Algoritmo de clasificación Unicode (UCA) basado en colaciones. Estos admiten bastante adaptación. Consulte su página de intercalaciones basadas en Algoritmo de clasificación Unicode para obtener detalles sobre cómo configurar el comportamiento, la convención de nomenclatura y la lista de configuraciones regionales válidas. Tenga en cuenta que en la Tabla 1, el ejemplo en la tercera fila ("Nivel de caso") comienza con:
Establecer el atributo Nivel de caso en activado y el atributo Fuerza en nivel primario ignorará el acento pero no el caso.
Eso es exactamente lo que estabas buscando. Sin embargo, la sintaxis para que sea:
CLDR181_EO_S1. Y esta es la razón por la que su búsqueda no encontró nada relacionado con DB2.
Oráculo
Oracle 10g agregó soporte para hacer comparaciones y clasificaciones insensibles al acento. Sin embargo:
- solo tienen las opciones para denotar operaciones "insensibles":
_CIy_AI
- solo puede especificar una de esas opciones a la vez
- la opción que no distingue entre mayúsculas y minúsculas
_CI- sigue siendo sensible al acento
- la opción insensible al acento -
_AI- "siempre distingue entre mayúsculas y minúsculas también". (Citado de su documentación que está vinculada a continuación)
Consulte su página de documentación de Clasificación lingüística y Búsqueda de cadenas para obtener más detalles y ejemplos.
SAP ASE (anteriormente Sybase ASE, también conocido como Sybase)
ASE admite una o más de las siguientes combinaciones de sensibilidades por cada configuración regional / juego de caracteres:
- sensible a mayúsculas y minúsculas
- insensible a mayúsculas y minúsculas
- insensible a mayúsculas y minúsculas, con preferencia
- insensible a mayúsculas y minúsculas
Puede ver la relación entre la configuración regional, el juego de caracteres y los órdenes de clasificación disponibles en su página Selección del orden de clasificación predeterminado . Y puede ver la lista completa de intercalaciones en su página de nombres e identificaciones de intercalación.
Su convención de nomenclatura de colación es arbitraria en el sentido de que son todos de 4 a 8 caracteres e intentan capturar el nombre de la configuración regional o la página de códigos y algo de sentido de la clasificación. Por ejemplo:
altnoacc== "Alternativa CP 850 - sin acento"
rusdict== "Orden de diccionario ruso"
dynix== "Orden de fonética china"
Hay una nota en su página Seleccionar el orden de clasificación Unicode predeterminado que dice:
Puede agregar órdenes de clasificación utilizando archivos externos en el $/collate/Unicodedirectorio. Los nombres y las identificaciones de colación se almacenan en syscharsets. Los nombres de los órdenes de clasificación Unicode externos no tienen que estar syscharsetsantes de poder establecer el orden de clasificación Unicode predeterminado.
...
SAP proporciona los órdenes de clasificación Unicode externos. No intente crear órdenes de clasificación Unicode externas.
No está claro si SAP proporcionaría o no un orden de clasificación externo para permitir mayúsculas y minúsculas. Tal vez algún día les envíe un correo electrónico y pregunte si se puede solicitar uno.
Para obtener la combinación deseada de sensibilidades, debe poder crear una función escalar definida por el usuario para quitar los acentos y otros signos diacríticos.
Informix (comprado por IBM)
Informix parece admitir principalmente el comportamiento predeterminado de clasificación y comparación de una Clasificación. Por lo tanto, las intercalaciones son solo la configuración regional y el conjunto de caracteres. La distinción entre mayúsculas y minúsculas se maneja a nivel de base de datos, y por defecto son sensibles a mayúsculas y minúsculas. Puede configurar una base de datos (no una tabla, una columna, una consulta o incluso un predicado) para que no distinga entre mayúsculas y minúsculas especificando NLSCASE INSENSITIVE en la CREATE DATABASEdeclaración.
Si bien la Clasificación de la base de datos (configuración regional y juego de caracteres) se puede anular por conexión de cliente, no parece haber una forma de anular la configuración de mayúsculas y minúsculas. Y, la NLSCASEopción tiene "NLS" en el nombre por una razón: solo afecta NCHARy NVARCHARdatos; CHARy VARCHARsiempre distinguen entre mayúsculas y minúsculas.
La sensibilidad de acento no se aborda, ni hay una función incorporada para eliminar los acentos / signos diacríticos.
La convención de nomenclatura de Informix Collation es:
<lang>_<country>.<code set>
dónde:
<lang> = un código de idioma de 2 letras o 3 letras<country> = un código de país o región de 2 letras<code set> = la página de códigos especificada en una de las 3 formas equivalentes siguientes:
- nombre: 8859-1
- valor decimal del número CCSID de IBM: 819
- valor hexadecimal del número CCSID de IBM: 0333
Por lo tanto, las siguientes tres especificaciones de configuración regional se refieren exactamente a la misma configuración regional:
- fr_fr.8859-1
- fr_fr.819
- fr_fr.0333
Para más información, consulte: