Exporter (0) Imprimer
Développer tout

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.

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.

ms143726.note(fr-fr,SQL.90).gifRemarque :
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'))
ms143726.note(fr-fr,SQL.90).gifRemarque :
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

Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.

Ajouts de la communauté

AJOUTER
Afficher:
© 2014 Microsoft