Terminologie relative au classement
Pour exploiter au mieux la prise en charge des langues dans SQL Server 2005, vous devez comprendre les termes définis dans cette rubrique.
Termes
- Page de codes
- Classement
- Type de données
- Globalisation
- Paramètres régionaux
- Sens de lecture
- Ordre de tri
- Unicode
Page de codes
Une page de codes est le jeu de caractères ordonné d'un script donné dans lequel un index numérique (ou une valeur de point de code) est associé à chaque caractère. Une page de codes Microsoft Windows est généralement appelée jeu de caractères. Les pages de codes permettent d'assurer la prise en charge des jeux de caractères et des dispositions du clavier utilisés par différents paramètres régionaux Windows.
Rubriques connexes :Définition des pages de codes clients
Retour en haut
Classement
Un classement désigne les modèles binaires qui représentent chaque caractère dans un jeu de données. Les classements déterminent également les règles de tri et de comparaison de données. SQL Server 2005 prend en charge le stockage d'objets qui ont des classements différents dans une base de données unique : dans une base de données SQL Server, chaque colonne peut avoir son propre classement. Pour les colonnes non-Unicode, le paramètre de classement spécifie la page de codes pour les données et par conséquent, les caractères qui peuvent être représentés. Les données peuvent être déplacées de manière transparente d'une colonne Unicode à l'autre. En revanche, elles ne peuvent pas être déplacées de manière transparente d'une colonne non-Unicode à l'autre et doivent être converties par la page de codes active.
Le résultat d'une instruction Transact-SQL peut varier lorsque cette dernière est exécutée dans un contexte réunissant plusieurs bases de données dont chacune a un paramètre de classement différent. Dans la mesure du possible, choisissez un classement standardisé pour votre organisation. En effet, un paramètre de classement standard appliqué à tous les systèmes de votre organisation vous évitera de devoir spécifier explicitement le classement dans chaque expression de caractères ou Unicode. Si vous devez utiliser des objets qui ont des paramètres de classement et de page de codes différents, vous devez coder vos requêtes conformément aux règles de priorité des classements. Pour plus d'informations, consultez Priorité de classement (Transact-SQL).
Un classement se caractérise par le respect de la langue, de la casse, des accents, des caractères Kana et de la largeur.
Les classements SQL Server 2005 incluent les regroupements suivants :
- Classements Windows
Les classements Windows définissent les règles de stockage des données de type caractère en fonction des paramètres régionaux associés. Pour un classement Windows, la comparaison de données non-Unicode est implémentée à l'aide du même algorithme que les données Unicode. Les règles de base du classement Windows spécifient l'alphabet ou la langue utilisée lorsque le tri du dictionnaire est appliqué, ainsi que la page de codes utilisée pour stocker les données de type caractère non-Unicode. Les tris Unicode et non-Unicode sont compatibles avec les comparaisons de chaînes dans une version particulière de Windows. Ceci permet de garantir la cohérence des types de données dans SQL Server et les développeurs peuvent ainsi trier les chaînes dans leurs applications en utilisant les mêmes règles que celles utilisées par SQL Server, c'est-à-dire en appelant la fonction CompareStringW de l'API Win32 Microsoft. Pour plus d'informations, consultez Paramètres de classement du programme d'installation.
Classements binaires
Les classements binaires trient les données selon la séquence de valeurs codées définie par les paramètres régionaux et le type de données. Un classement binaire de SQL Server définit la langue et la page de codes ANSI à utiliser, en appliquant un ordre de tri binaire. Grâce à leur relative simplicité, les classements binaires aident à renforcer les performances applicatives. Pour les données de type non-Unicode, les comparaisons de données se basent sur les points de code définis dans la page de codes ANSI. Pour les données de type Unicode, les comparaisons de données se basent sur les points de code Unicode. Pour le classement binaire des types de données Unicode, les paramètres régionaux (la langue) ne sont pas pris en compte dans les tris de données. Par exemple, Latin_1_General_BIN et Japanese_BIN produisent des résultats de tri identiques s'ils sont utilisés avec des données Unicode.Les classements binaires des versions précédentes de SQL Server effectuaient une comparaison des points de code incomplète pour les données Unicode, car ils comparaient le première caractère comme WCHAR, suivi d'une comparaison octet par octet. Pour des raisons de compatibilité descendante, la sémantique des classements binaires existante ne sera pas modifiée.
Les classements binaires de cette version de SQL Server incluent un nouvel ensemble de classements de comparaison de points de code purs. Les clients peuvent choisir de migrer vers les nouveaux classements binaires pour bénéficier des comparaisons de points de code et il est conseillé d'utiliser ces nouveaux classements pour développer des applications. Le nouveau suffixe BIN2 identifie le nom des classements qui implémentent la sémantique des nouveaux classements par points de code. En outre, un nouvel indicateur de comparaison est ajouté et correspond à BIN2 pour le nouveau tri binaire. Pour plus d'informations, consultez Utilisation des classements binaires.
Classements SQL Server
Les classements SQL Server permettent d'assurer une compatibilité avec les ordres de tri des versions précédentes de SQL Server. Les classements SQL Server se basent sur les ordres de tri SQL Server hérités pour les données non-Unicode - par exemple, les types de données char et varchar - définis dans SQL Server. Les règles de tri du dictionnaire pour les données non-Unicode ne sont pas compatibles avec les routines de tri fournies par les systèmes d'exploitation Windows, mais le tri des données Unicode est compatible avec les règles de tri d'une version particulière de Windows. Étant donné que les classements SQL Server utilisent des règles de comparaison différentes pour les données Unicode et non-Unicode, vous pouvez obtenir des résultats différents pour des comparaisons traitant des mêmes données, selon le type de données sous-jacent. Pour plus d'informations, consultez Utilisation des classements SQL.Remarque : Lorsque vous mettez à niveau une instance SQL Server, vous pouvez spécifier les classements SQL Server pour permettre la compatibilité avec les instances SQL Server existantes. Le classement par défaut d'une instance SQL Server étant défini au cours de l'installation, il est important de spécifier soigneusement les paramètres de classement dans les cas suivants : - Votre code d'application dépend d'une certaine manière du comportement des classements SQL Server précédents.
- Vous utiliserez la fonctionnalité de réplication SQL Server 2005 avec des instances existantes de SQL Server version 6.5 ou SQL Server version 7.0.
- Vous devez stocker des données de caractères de plusieurs langues.
SQL Server 2005 assure le paramétrage des classements aux niveaux suivants d'une instance SQL Server 2005 :
Classements au niveau du serveur
Le classement par défaut d'une instance SQL Server est défini au cours de l'installation. Le classement par défaut de l'instance devient également le classement par défaut des bases de données système : master, model, tempdb, msdb et distribution. Lorsqu'un classement a été attribué à un objet autre qu'une colonne ou une base de données, vous ne pouvez le modifier qu'en supprimant et en recréant l'objet. Au lieu de modifier le classement par défaut d'une instance SQL Server, vous pouvez spécifier un classement pour chaque nouvelle base de données ou colonne de base de données.Pour demander le classement du serveur dans une instance SQL Server, utilisez la fonction Transact-SQL SERVERPROPERTY suivante :
SELECT CONVERT (varchar, SERVERPROPERTY('collation'))
Pour demander au serveur tous les classements disponibles, utilisez la fonction intégrée fn_helpcollations() suivante :
SELECT * from ::fn_helpcollations()
Classements au niveau de la base de données
Lorsque vous créez une base de données, vous pouvez utiliser la clause COLLATE de l'instruction CREATE DATABASE pour spécifier le classement par défaut de la base de données. Si aucun classement n'est spécifié durant la création d'une base de données, cette dernière a le classement par défaut de la base de données model. Le classement par défaut de la base de données model est le même que celui de l'instance SQL Server.Le classement d'une base de données utilisateur peut être modifié avec une instruction ALTER DATABASE telle que :
ALTER DATABASE myDB COLLATE Greek_CS_AI
Le classement actif d'une base de données peut être extrait à l'aide d'une instruction telle que :
SELECT CONVERT (varchar, DATABASEPROPERTYEX('database_name','collation'))
Remarque : Le fait de changer le classement au niveau de la base de données n'a aucune incidence sur les classements au niveau de l'utilisateur, des tables et des colonnes.
Classements au niveau des colonnes
Lorsque vous créez une table, vous pouvez spécifier des classements pour chaque colonne de chaînes de caractères à l'aide de la clause COLLATE de l'instruction CREATE TABLE. Si aucun classement n'est spécifié durant la création d'une table, cette dernière a le classement par défaut de la base de données.Le classement d'une colonne peut être modifié avec une instruction ALTER TABLE telle que :
ALTER TABLE myTable ALTER COLUMN mycol NVARCHAR(10) COLLATE Greek_CS_AI
Classements au niveau de l'expression
Les classements au niveau de l'expression sont définis au moment de l'exécution d'une instruction et ils affectent la façon dont l'ensemble de résultats est retourné. Ceci permet de trier un résultat de sorte que la clause ORDER BY puisse être spécifique à la langue. Utilisez une clause COLLATE telle que la suivante pour implémenter des classements au niveau de l'expression :SELECT name FROM customer ORDER BY name COLLATE Latin1_General_CS_AI
Retour en haut
Type de données
Le type de données est une définition qui spécifie une plage de valeurs, les opérations qui peuvent être effectuées sur ces valeurs et la façon dont les valeurs sont stockées dans la mémoire de l'ordinateur. La définition de types de données permet à SQL Server de manipuler les données de façon prévisible. Les types de données de caractères non-Unicode sont char, varchar et text. Les types de données Unicode utilisent la représentation de caractères Unicode ; ce sont nchar, nvarchar et ntext. Vous devriez utiliser les types de données Unicode dans vos applications, notamment si vous stockez des données de caractères de plusieurs langues.
Rubriques connexes :Types de données (Moteur de base de données), Types de données (Transact-SQL), Types de données d'Integration Services
Retour en haut
Globalisation
La globalisation est un processus qui consiste à développer une application logicielle présentant des caractéristiques et un code conçus pour plusieurs langues et paramètres régionaux. La conception d'une application globalisée intègre une multiplicité de paramètres régionaux et de langues prises en charge par Unicode pour l'entrée, le traitement, l'affichage et la sortie de données.
Rubriques connexes :Considérations internationales relatives à SQL Server
Retour en haut
Paramètres régionaux
Les paramètres régionaux représentent un ensemble d'informations associées à un lieu ou à une culture telles que le nom et l'identificateur de la langue parlée, le script utilisé pour écrire la langue et les conventions culturelles. SQL Server 2005 prend en charge les 135 langues prises en charge par Windows XP. Parmi elles figurent cinq langues chinoises (RAS de Hong Kong, RAS de Macao, République populaire de Chine, Singapour et Taïwan), treize langues anglaises (Australie, Belize, Canada, Caraïbes, Irlande, Jamaïque, Nouvelle-Zélande, Philippines, Afrique du Sud, île de la Trinité, le Royaume-Uni, les États-Unis d'Amérique et Zimbabwe) et six langues françaises (Belgique, Canada, France, Luxembourg, Monaco et Suisse).
Le tableau suivant illustre plusieurs différences entre quatre paramètres régionaux courants pris en charge par Windows.
Paramètres régionaux | Anglais (États-Unis) | Français (France) | Japonais | Émirats arabes unis |
---|---|---|---|---|
Pays/région |
États-Unis |
France |
Japon |
Émirats arabes unis |
Langue |
Anglais |
Français |
Japonais |
Arabe |
Scripts écrits |
Latin |
Latin |
Kana, kanji |
Arabe |
Sens de lecture |
De gauche à droite |
De gauche à droite |
De gauche à droite |
De droite à gauche |
Page de codes définie par Windows |
1252 |
1252 |
932 |
1256 |
Format horaire |
13:00:00 AM |
13:00 |
13:00 |
1:00 p |
Calendrier |
Grégorien |
Grégorien |
Grégorien (localisé) |
Grégorien (localisé) |
Format de papier par défaut |
Lettre US |
A4 |
A4 |
A4 |
Séparateur décimal |
. |
, |
. |
, |
Séparateur de liste |
, |
; |
, |
; |
Séparateur de milliers |
, |
espace |
, |
, |
Retour en haut
Sens de lecture
Le sens de lecture est la direction globale d'une séquence de texte ordonnée, relative à l'ordre des mots et non à l'ordre des caractères saisis. Par exemple, l'utilisation de l'arabe comme langue du clavier signifie que les nouveaux caractères apparaissent de la droite vers la gauche. Lorsque la langue du clavier est le latin, les nouveaux caractères apparaissent de la gauche vers la droite.
Retour en haut
Ordre de tri
L'ordre de tri désigne la façon dont les valeurs de données sont triées, ce qui affecte les résultats des comparaisons de données. Le tri des données est réalisé par le biais de classements et il peut être optimisé à l'aide d'index.
Rubriques connexes :Styles de tri des classements Windows, Index
Retour en haut
Unicode
Unicode représente les caractères d'une langue avec deux octets plutôt qu'un, ce qui permet à un seul jeu de caractères Unicode de représenter la quasi-totalité des langues écrites du monde. Unicode a été développé et est mis à jour et promu par le consortium Unicode, une organisation informatique à but non lucratif. Pour plus d'informations, consultez le site Web du consortium Unicode (en anglais).
Si vous stockez des données de caractères de plusieurs langues, utilisez toujours les types de données Unicode (nchar, nvarchar et ntext) plutôt que les types de données non-Unicode (char, varchar et text). Vous obtiendrez un gain sensible des performances en utilisant Unicode, car il y aura moins de conversions de pages de codes requises. Les types de données non-Unicode entraînent des restrictions importantes, car un ordinateur non-Unicode se limite à utiliser une page de codes unique. Pour étudier soigneusement les questions liées à l'utilisation des types de données Unicode ou non-Unicode, vous devez tester les deux cas de figure et mesurer les écarts de performances dans votre environnement propre. Vous devez au moins standardiser le classement du site et déployer des serveurs et clients Unicode partout où vous le pouvez.
Dans la plupart des cas, votre instance SQL Server entre en interaction avec d'autres serveurs ou clients et elle peut utiliser de multiples standards d'accès aux données. Les clients SQL Server sont l'un des deux types principaux :
- Les clients Unicode qui utilisent OLE DB et ODBC (Open Database Connectivity) version 3.7 ou ultérieure.
- Les clients non-Unicode qui utilisent DB-Library et ODBC version 3.6 ou antérieure.
Le tableau suivant présente des recommandations pour utiliser des données multilingues avec diverses combinaisons de serveurs Unicode et non-Unicode.
Serveur | Client | Avantages ou restrictions |
---|---|---|
Unicode |
Unicode |
Configuration idéale, car les données Unicode seront utilisées dans tout le système. Ce scénario fournit les meilleures performances et la meilleure protection contre l'endommagement des données récupérées. Ceci se produit avec Microsoft ActiveX Data Objects (ADO), OLE DB et ODBC version 3.7 ou ultérieure. |
Unicode |
Non-Unicode |
Dans cette configuration, le stockage des données ne pose probablement pas de problème, mais les restrictions sont nombreuses lorsque vous déplacez les données vers un ordinateur client. Les données Unicode doivent au minimum être converties à l'aide de la page de codes du client non-Unicode. |
Non-Unicode |
Unicode |
Cette configuration n'est pas idéale pour utiliser des données multilingues. Vous ne pouvez pas écrire des données Unicode sur le serveur non-Unicode. Des problèmes peuvent survenir lorsque les données sont envoyées à des serveurs qui sont en dehors de la page de codes du serveur. |
Non-Unicode |
Non-Unicode |
Cette configuration est la plus limitée pour des données multilingues. Vous ne pouvez utiliser qu'une seule page de codes. La configuration idéale est un serveur Unicode avec des clients Unicode. |
Rubriques connexes :Unicode : concepts de base
Retour en haut
Voir aussi
Référence
Options de classement et prise en charge internationale