TL; DR
Il n'y a rien de tel qu'une vue «indépendante du fournisseur» des classements, ni même «indépendante de la version», car leurs implémentations - y compris les aspects qui peuvent être rendus insensibles et leurs conventions de dénomination - sont spécifiques au fournisseur et changent avec le temps. .
Voici un résumé de ce que j'ai trouvé, et les détails se trouvent dans la section plus longue sous la ligne:
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
Comme vous pouvez le voir dans le graphique, deux des sept SGBDR prennent en charge nativement les opérations «sensibles à la casse et insensibles à l'accent» via les classements, bien qu'elles aient des conventions de dénomination différentes (et plusieurs autres différences fonctionnelles).
Un SGBDR - PostgreSQL - ne prend pas en charge nativement cette combinaison, mais vous pouvez toujours y parvenir en supprimant les accents avec la fonction unaccent()complémentaire.
Les quatre derniers SGBDR, dont deux ont une convention de dénomination similaire pour les options, ne prennent pas en charge cette combinaison de manière native et il ne semble pas y avoir de moyen d'y parvenir sans écrire votre propre fonction pour supprimer les accents / signes diacritiques. MySQL permet de créer vos propres classements, mais cela nécessite que vous l'ajoutiez ensuite au contrôle de source et l'incorporiez dans votre processus de test et de déploiement afin qu'il puisse être appliqué à tous les serveurs dans tous les environnements (mais toujours une option très cool et flexible) . SAP ASE mentionne que SAP peut fournir des ordres de tri Unicode supplémentaires, mais aucune mention de ce qu'ils pourraient être disposés à fournir.
En ce qui concerne:
Y a-t-il une bonne raison à cela ou le mien n'est-il qu'un cas d'utilisation rare?
Je peux dire qu'en faisant la recherche de cette réponse, je suis tombé sur de nombreux cas de personnes voulant insensibles à la casse et sensibles à l'accent pour MySQL, mais peu, le cas échéant, demandant la combinaison souhaitée.
Je voulais une condition de recherche pour utiliser un classement sensible à la casse mais insensible à l'accent mais je n'ai pas pu en trouver un.
...
cette question est indépendante du fournisseur / de la version
Votre recherche a échoué, car il n'est pas vraiment logique de rechercher un SGBDR basé sur une spécification de classement. Ce n'est tout simplement pas ainsi que fonctionnent les classements. Et bien que vous souhaitiez aborder cela comme indépendant du fournisseur, la réalité est que les classements - au moins la partie avec laquelle nous interagissons - sont très spécifiques au fournisseur et ne correspondent pas toujours au schéma sur lequel vous recherchiez. .
La comparaison et le tri des chaînes sont très complexes, et il existe différentes façons d'appliquer ces règles. Une méthode consiste à avoir des mappages qui prennent en compte une ou plusieurs règles. Par conséquent, les quatre combinaisons de Sensitive et Insensible pour Case et Accents équivaudraient à quatre mappages distincts. Par exemple, vous l'avez vu sur cette page MSDN pour le nom de classement SQL Server . Si vous faites défiler vers le bas, vous verrez que la colonne de gauche du graphique est le Sort Order ID. Chaque classement a un ID différent: SQL_Latin1_General_Cp1_CI_AS= 52 tandis que SQL_Latin1_General_Cp1_CS_AS= 51, même si la seule différence est dans la sensibilité à la casse.
Ou, il peut être basé sur des règles, comme ce que propose Unicode via l'algorithme de classement Unicode (UCA). Dans cette approche, chaque caractère reçoit, par défaut, un ou plusieurs poids. Ensuite, chaque culture / paramètre régional a la possibilité de remplacer l'un de ces poids, ou de supprimer des règles, ou d'ajouter des règles. L'algorithme prend en compte toutes les règles spécifiques aux paramètres régionaux, puis manipule potentiellement ces pondérations en fonction de toutes les options choisies (sensibilité, le cas vient en premier lorsque vous effectuez des tris sensibles à la casse, etc.). C'est une des raisons pour lesquelles le tri Unicode est un peu plus lent que le tri non Unicode.
Pour avoir une idée du nombre d'options réellement disponibles (c'est-à-dire de la complexité réelle), consultez cette démo du projet ICU (International Components for Unicode):
ICU Collation Demo
Il y a 8 options distinctes pour spécifier, et certains d'entre eux sont représentées dans un plusieurs éléments de la spécification du nom Collation que vous pensez (par exemple CS, CI, AS, AI, etc.). Étant donné le nombre de variantes, l'utilisation de l'approche de fichier de mappage où chaque combinaison a son propre ID entraînerait plusieurs milliers de fichiers. Beaucoup de ces fichiers devraient être mis à jour chaque fois qu'il y a des changements dans ces langues particulières, ou lorsque des bogues sont détectés. C'est probablement pourquoi il n'y a que 75 de ces types de classements dans SQL Server 2012 (c'est-à-dire ceux dont les noms commencent par SQL_). Par conséquent, aucune combinaison pour _CS_AI.
Et la raison pour laquelle vous n'avez pas trouvé cette combinaison pour les collations basées sur l'UCA? Eh bien, il y a 3810 collations dans SQL Server 2012 qui ne commencent pas SQL_, donc 3885 collations au total. Cette liste semble trop longue pour être entièrement énumérée sur une page Web. Mais cela n'explique pas entièrement pourquoi vous n'avez pas pu trouver cette combinaison pour d'autres fournisseurs.
Au-delà de ce qui a déjà été mentionné (c'est-à-dire trop de combinaisons à implémenter et trop d'implémentations à répertorier), vous devez toujours faire face à des implémentations spécifiques au fournisseur. Signification: tous les fournisseurs ne permettent pas de personnaliser toutes ces options, et il n'y a pas de convention de dénomination standard pour les classements en premier lieu. En outre, tous les fournisseurs ne considèrent pas les options de tri comme faisant partie du classement: les classements PostgreSQL sont classés par défaut pour les paramètres régionaux choisis, et vous devez les utiliser ILIKEpour obtenir une comparaison insensible à la casse. Voir ci-dessous pour des informations spécifiques au fournisseur.
SQL Server (Microsoft)
La distinction entre ce que vous voyez sur ces deux pages de documentation MSDN et la requête fournie par @MartinSmith dans un commentaire sur la question (légèrement révisée ci-dessous):
SELECT *
FROM sys.fn_helpcollations()
WHERE [name] LIKE '%[_]CS[_]AI%';
est que ces deux pages MSDN font spécifiquement référence aux classements SQL Server très déconseillés, tandis que les classements qui apparaissent à la suite de cette requête (888 d'entre eux à partir de SQL Server 2012, SP3) sont des classements Windows.
À partir de SQL Server 2000, les anciens classements SQL Server (créés avant que SQL Server puisse accéder aux classements Windows) sont obsolètes et ne sont pas mis à jour avec de nouvelles règles ou fonctionnalités. Par exemple, à partir de SQL Server 2012, un ensemble de classements a été ajouté qui prend en charge la gestion appropriée des fonctions intégrées pour les caractères supplémentaires (c'est-à-dire les caractères UTF-16 restants au-delà des 65 536 caractères "de base" définis initialement dans UCS-2). ). Ces nouveaux classements se terminent par _SC(comme dans S upplementary C haracters).
Il est préférable de ne pas utiliser les classements SQL Server - ceux dont le nom commence par SQL_. Par conséquent, vous avez accès à de nombreux classements qui prennent en charge la combinaison d'options que vous recherchez (c'est-à-dire sensible à la casse et sensible à l'accent). Lorsqu'elles sont disponibles, il est également préférable d'utiliser une extrémité dans la _SCmesure où elle dispose de toutes les autres options souhaitées.
Bien que SQL Server utilise la _CS_AIconvention de dénomination, il n'y a pas de liste de tous les classements Windows 3810 (à partir de SQL Server 2012). Il n'y a que la page Nom du classement Windows qui répertorie tous les paramètres régionaux et versions, et comment fonctionne la convention de dénomination, mais c'est tout.
SQL Server prend également en charge le basculement de la sensibilité Largeur et Kana.
MySQL (acheté par Oracle)
La version MySQL 5.7, la documentation précise qu'il prend en charge l' _ai, _as, _ci, et _cssuffixes (et _binpour être complet), mais indique également:
Pour les noms de classement non binaires qui ne spécifient pas la sensibilité d'accentuation, il est déterminé par la sensibilité à la casse. Autrement dit, si un nom de classement ne contient pas _aiou _as, _cidans le nom implique _aiet _csdans le nom implique _as.
Par exemple, latin1_general_ciest insensible à la casse (et insensible à l'accent, implicitement), latin1_general_csest sensible à la casse (et sensible à l'accent, implicitement)
Cela implique certainement qu'il est possible d'avoir un latin1_general_cs_aiclassement. Cependant, le serveur MySQL 5.5.50 que j'ai accès à ne pas de plus avec les classements un suffixe, et les suffixes que je vois sont: _cs, _ciet _binsur 198 au total classements. J'ai utilisé la commande SHOW COLLATION pour les répertorier.
Donc, même s'il semble que MySQL utilise une convention de dénomination similaire (au moins en ce qui concerne ces deux options), je ne trouve pas de classement correspondant à ce que vous recherchez. Cependant, il pourrait être possible de supprimer les accents (et autres marques diacritiques) et d'utiliser un _csclassement pour obtenir ce que vous voulez (similaire à la façon dont vous le feriez dans PostgreSQL - voir ci-dessous). Mais je ne suis pas sûr de cette option et je n'ai pas le temps pour le moment de poursuivre mes recherches.
OU , vous pourriez créer votre propre Collation pour faire exactement ce que vous voulez. Contrairement aux autres SGBDR, MySQL semble simplifier l'ajout de vos propres classements, auquel cas vous contrôlez entièrement la pondération de chaque caractère. Veuillez voir Ajouter un classement simple à un jeu de caractères 8 bits et Ajouter un classement UCA à un jeu de caractères Unicode pour plus de détails.
Pour plus d'informations sur la façon dont MySQL gère différents types de classements, veuillez consulter leur page Types d'implémentation de classement .
PostgreSQL
Les classements dans PostgreSQL semblent être beaucoup moins flexibles. Vous spécifiez uniquement la culture / locale: en_US, de_DE, etc. S'il vous plaît voir leur page de documentation pour Collation support pour plus de détails. Par conséquent, par défaut, vous obtenez les remplacements spécifiques à la culture, mais les classements sont par ailleurs tout sensibles (ce qui, en passant, n'est pas identique à un classement "binaire").
Vous pouvez utiliser ILIKE (section 9.7.1) pour obtenir une insensibilité à la casse, mais ils n'ont pas d'opérateur similaire pour la sensibilité aux accents. Cependant, j'ai trouvé qu'ils ont une fonction non accentuée qui peut être utilisée pour supprimer les accents et autres marques diacritiques. Veuillez noter que cette fonction est un module supplémentaire fourni et n'est donc pas nécessairement présente dans un serveur PostgreSQL particulier à utiliser. La dernière documentation liée indique:
Lors de la construction à partir de la distribution source, ces composants ne sont pas construits automatiquement, à moins que vous ne construisiez la cible "mondiale"
...
Si vous utilisez une version pré-packagée de PostgreSQL, ces modules sont généralement mis à disposition sous la forme d'un sous-package séparé, tel que postgresql-contrib.
Veuillez consulter cette documentation pour savoir comment obtenir cette fonction si vous ne l'avez pas et que vous la souhaitez.
Plus d'informations peuvent également être trouvées dans la réponse Stack Overflow suivante:
PostgreSQL prend-il en charge les classements «insensibles aux accents»?
DB2 (IBM)
Semblable à Microsoft SQL Server, DB2 propose deux types de classements:
« SYSTEM », qui sont la collation par défaut spécifiées en utilisant le format suivant: SYSTEM_{codepage}_[optional-territory]. Ceux-ci ne sont pas très flexibles et ne semblent pas prendre en charge la sensibilité de la casse, des accents ou de quoi que ce soit. Vous pouvez trouver la liste des classements pris en charge ici: Codes de territoire pris en charge et pages de codes
Collations basées sur l'algorithme de classement Unicode (UCA). Ceux-ci prennent en charge un peu de personnalisation. Veuillez consulter leur page de classements basés sur l'algorithme de classement Unicode pour plus de détails sur la configuration du comportement, la convention de dénomination et la liste des paramètres régionaux valides. Veuillez noter que dans le tableau 1, l'exemple de la troisième ligne ("Niveau de cas") commence par:
La définition de l'attribut Case Level sur On et l'attribut Strength au niveau primaire ignoreront l'accent mais pas la casse.
C'est exactement ce que vous recherchiez. Mais, la syntaxe pour cela est:
CLDR181_EO_S1. Et c'est pourquoi votre recherche n'a trouvé aucun élément lié à DB2.
Oracle
Oracle 10g a ajouté la prise en charge des comparaisons et du tri insensibles aux accents. Pourtant:
- ils n'ont que les options pour désigner les opérations "insensibles":
_CIet_AI
- vous ne pouvez spécifier qu'une de ces options à la fois
- l'option insensible à la casse -
_CI- est toujours sensible aux accents
- l'option insensible à l'accent -
_AI- "est toujours également insensible à la casse." (cité à partir de leur documentation qui est liée ci-dessous)
Veuillez consulter leur page de documentation sur le tri linguistique et la recherche de chaînes pour plus de détails et d'exemples.
SAP ASE (anciennement Sybase ASE, alias Sybase)
ASE prend en charge une ou plusieurs des combinaisons de sensibilités suivantes pour chaque paramètre régional / jeu de caractères:
- sensible à la casse, sensible à l'accent
- insensible à la casse, sensible à l'accent
- insensible à la casse, sensible à l'accent, ordre de préférence
- insensible à la casse, insensible à l'accent
Vous pouvez voir la relation entre les paramètres régionaux, le jeu de caractères et les ordres de tri disponibles sur leur page Sélection de l'ordre de tri par défaut . Et vous pouvez voir la liste complète des classements sur leur page Noms et ID de classement .
Leur convention de dénomination de classement est arbitraire en ce sens qu'ils sont tous de 4 à 8 caractères et tentent de capturer le nom de l'environnement local ou la page de codes et un certain sens du tri. Par exemple:
altnoacc== "Alternative au CP 850 - sans accent"
rusdict== " Ordre du dictionnaire russe"
dynix== "Ordre phonétique chinois"
Il y a une note sur leur page Sélection de l'ordre de tri par défaut Unicode indiquant:
Vous pouvez ajouter des ordres de tri à l'aide de fichiers externes dans le $/collate/Unicoderépertoire. Les noms et les ID de classement sont stockés dans syscharsets. Il n'est pas nécessaire que les noms des ordres de tri Unicode externes soient inclus syscharsetsavant de pouvoir définir l'ordre de tri Unicode par défaut.
...
Les ordres de tri Unicode externes sont fournis par SAP. N'essayez pas de créer des ordres de tri Unicode externes.
On ne sait pas si oui ou non SAP fournirait un ordre de tri externe pour permettre la casse et Accent-Insensible. Peut-être qu'un jour je leur enverrai un e-mail et leur demanderai si l'on peut en demander un.
Afin d'obtenir la combinaison souhaitée de sensibilités, vous devriez pouvoir créer une fonction scalaire définie par l'utilisateur pour supprimer les accents et autres marques diacritiques.
Informix (acheté par IBM)
Informix semble ne prendre en charge que le comportement de tri et de comparaison par défaut d'un classement. Par conséquent, les classements ne sont que les paramètres régionaux et le jeu de caractères. La casse est gérée au niveau de la base de données et, par défaut, elle est sensible à la casse. Vous pouvez définir une base de données (pas une table, ou une colonne, ou une requête, ou même un prédicat) pour être insensible à la casse en spécifiant NLSCASE INSENSITIVE dans l' CREATE DATABASEinstruction.
Bien que le classement de la base de données - paramètres régionaux et jeu de caractères - puisse être remplacé par une connexion client, il ne semble pas y avoir de moyen de remplacer le paramètre de respect de la casse. ET, l' NLSCASEoption a « SNA » dans le nom pour une raison: il ne touche que NCHARet les NVARCHARdonnées; CHARet VARCHARsont toujours sensibles à la casse.
La sensibilité aux accents n'est pas abordée, et il n'y a pas de fonction intégrée pour supprimer les accents / signes diacritiques.
La convention de dénomination d'Informix Collation est la suivante:
<lang>_<country>.<code set>
où:
<lang> = un code de langue à 2 ou 3 lettres<country> = un code de pays ou de région à 2 lettres<code set> = la page de codes spécifiée de l'une des 3 manières équivalentes suivantes:
- nom: 8859-1
- valeur décimale du numéro IBM CCSID: 819
- valeur hexadécimale du numéro IBM CCSID: 0333
Par conséquent, les trois spécifications locales suivantes font toutes référence aux mêmes paramètres régionaux:
- fr_fr.8859-1
- fr_fr.819
- fr_fr.0333
Pour plus d'informations, veuillez consulter: