Incidence des données Unicode sur le stockage et les performances
SQL Server stocke les données Unicode à l'aide du schéma de codage UCS-2. Avec ce mécanisme, tous les caractères Unicode sont stockés à l'aide de 2 octets.
Le choix du stockage des données au format Unicode ou non-Unicode dépend du fait que les données non-Unicode sont stockées, ou non, à l'aide de jeux de caractères codés sur deux octets. Toutes les langues qui ne sont pas des langues d'Extrême-Orient et la langue Thaï stockent les caractères non-Unicode en utilisant un codage sur un octet. Par conséquent, le stockage de ces langues au format Unicode utilise deux fois plus d'espace que pour la spécification d'une page de codes non-Unicode. D'autre part, les pages de codes non-Unicode de nombreuses langues d'Extrême-Orient spécifient le stockage des caractères dans des jeux de caractères codés sur deux octets (DBCS). Par conséquent, pour ces langues, il n'existe pratiquement aucune différence entre le stockage non-Unicode et Unicode.
Le tableau suivant présente les pages de codes non-Unicode qui spécifient le stockage des données dans des jeux de caractères codés sur deux octets.
Langue |
Page de codes |
|---|---|
Chinois simplifié |
936 |
Chinois traditionnel |
950 |
Japonais |
932 |
Coréen |
949 |
L'incidence des données Unicode sur les performances est accentuée par divers facteurs répertoriés ci-après :
différence entre les règles de tri Unicode et non-Unicode ;
différence entre le tri des caractères codés sur un octet et des caractères codés sur deux octets ;
conversion des pages de codes entre le client et le serveur.
SQL Server effectue des comparaisons de chaîne des données non-Unicode définies avec un classement Windows en utilisant des règles de tri Unicode. Compte tenu que ces règles sont beaucoup plus complexes que les règles de tri non-Unicode, elles utilisent une plus grande quantité de ressources. Aussi, bien que les règles de tri Unicode soient souvent plus coûteuses, il y a généralement peu de différence en termes de performances entre les données Unicode et les données non-Unicode définies à l'aide d'un classement Windows.
SQL Server utilise les règles de tri non-Unicode uniquement sur les données non-Unicode qui sont définies à l'aide d'un classement SQL. Les analyses et les tris dans cette instance sont généralement plus rapides que lorsque des règles de tri Unicode sont appliquées. Les règles de tri Unicode s'appliquent à toutes les données Unicode définies à l'aide d'un classement Windows ou d'un classement SQL.
Le tri de nombreuses données Unicode peut être plus lent que celui des données non-Unicode, car les données sont stockées sur deux octets. D'autre part, le tri des caractères asiatiques dans Unicode est plus rapide que celui des données asiatiques de jeux de caractères codés sur deux octets dans une page de codes spécifique, car les données de jeux de caractères codés sur deux octets sont en fait une combinaison de largeurs d'un octet et de deux octets, alors que les caractères Unicode sont de largeur fixe.
D'autres problèmes de performances sont principalement liés au problème de conversion du mécanisme de codage entre une instance de SQL Server et le client. En général, l'incidence de la conversion des pages de codes client/serveur sur les performances est négligeable. Vous devez néanmoins comprendre ce qui se produit au niveau de cette couche.
L'API ODBC (version 3.6 ou antérieure) et l'API DB-Library ne reconnaissent pas Unicode. Pour les clients qui utilisent des méthodes d'accès aux données définies par ces API, les ressources sont utilisées pour convertir implicitement des données Unicode dans la page de codes du client. De plus, il existe un risque d'altération des données côté client lorsque la page de codes du client ne reconnaît pas certains caractères Unicode.
Les versions ultérieures de ODBC, à partir de MDAC (Microsoft Data Access Components) version 2.7 qui était inclus dans SQL Server version 7.0, ainsi que OLE DB et ADO reconnaissent Unicode et adoptent un mécanisme de codage UCS-2. Par conséquent, si l'application gère Unicode, vous ne rencontrez aucun problème de conversion lorsque vous utilisez exclusivement des données Unicode d'une instance de SQL Server. Si un client utilise une API qui gère Unicode mais si le mécanisme de stockage des données dans l'instance de SQL Server n'est pas Unicode, il n'existe aucun problème de conversion. Cependant, il est possible que les opérations d'insertion ou de mise à jour des données soient endommagées si les points de code des caractères ne peuvent pas être associés à la page de codes SQL Server.
Méthodes conseillées pour Unicode
Le choix du stockage des données non-DBCS au format Unicode repose généralement sur une évaluation préalable des conséquences sur le stockage, de l'altération éventuelle des données, et des opérations de tri et de conversion qui pourront intervenir lors des interactions client avec les données. La conversion et le tri peuvent avoir des conséquences sur les performances, en fonction de l'endroit où ces opérations interviennent. Cette incidence est toutefois négligeable pour la plupart des applications. Les bases de données dotées d'index correctement conçus ne sont généralement pas affectées. Cependant, l'altération des données aura une incidence non seulement sur l'intégrité d'une application et d'une base de données, mais aussi sur l'ensemble des activités. Si l'on prend en compte cet inconvénient, le stockage des données de caractères dans une page de codes spécifique peut être judicieux si les deux situations suivantes sont vérifiées :
la conservation d'un espace de stockage est un problème en raison des limitations au niveau matériel. Ou, vous triez fréquemment d'importantes quantités de données et les tests indiquent qu'un mécanisme de stockage Unicode diminue considérablement les performances ;
vous êtes certain que les pages de codes de tous les clients qui accèdent à ces données correspondent aux vôtres, et cette situation ne changera pas de manière inattendue.
Le plus souvent, la décision de stocker des données de caractères (même les données non-DBCS) au format Unicode doit reposer sur les besoins de l'entreprise plutôt que sur les performances. Dans le contexte d'une économie mondiale favorisée par la croissance rapide du trafic Internet, il est désormais essentiel de gérer des ordinateurs clients qui utilisent des paramètres régionaux différents. En outre, il est de plus en plus difficile de choisir une page de codes qui prend en charge tous les caractères requis par une audience internationale.