unicode

Le problème c'est que dans la plupart des cas, il n'y a pas vraiment
d'avantage de vitesse à utiliser l'ANSI en lieu et place de l'Unicode. On
entend souvent le commentaire à l'effet que l'on est des pros, que l'on
programme uniquement qu'est-ce qu'il y a de mieux et que par conséquent, on
utilise l'ANSI afin que le système aille deux fois plus vite.
Malheureusement, si on prend la peine de tester la chose, la dite
augmentation de 100% de la vitesse n'est dans la plupart des cas qu'à peine
l'ombre d'elle-même.

Bien des commentaires entendus ici et là tombent une fois que l'on prend la
peine d'en vérifier la réalité et même là, souvent ceux qui font des tests
en choisissent qui n'ont pratiquement aucune relation avec la réalité. Par
exemple, la majorité des tests de performance s'effectuent à 100% de la
capacité du CPU; ce qui n'a rien à voir avec une très grande majorité de
cas. Un 10% de vitesse supplémentaire mesurée lorsque le CPU roule à 100%
sera probablement totalement imperceptible lorsque ce dernier roulera à une
moyenne de 30%.

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)


"Patrice" <http://www.chez.com/scribe/> wrote in message
news:eBWqOg57HHA.5404@TK2MSFTNGP02.phx.gbl...

De mon côté, il me parait un peu extrème de préconiser une utilisation
*systématique* de unicode (ou j'ai mal compris) notamment sans que l'OP
ait précisé si c'est une base interne à l'entreprise, destinée à des
clients internationaux etc (à priori il n'envisage d'utiliser que du
français et les "clients" (au sens technique) ne sont pas précisés)...

De plus, le passage en unicode n'est pas spécialement compliqué à faire si
cela devenait réellement nécessaire un jour.

Ici on a les deux en fonction des besoins. Je ne m'"obstine" pas à garder
ANSI. Je préfère simplement choisir la solution la plus logique et donc
pas d'unicode quand je n'en ai aucunement besoin.

Après je suis d'accord aussi que le pb est parfois un manque de vision
d'ensemble (parfois des pbs lorsqu'on oublie que le codage se maitrise de
bout en bout et que ce n'est pas parce qu'on a de l'unicode en base, qu'il
ne faut pas s'occuper des écritures en fichier, vers les navigateurs
etc...)

--
Patrice

"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> a
écrit dans le message de news: uWE9aEx7HHA.536@TK2MSFTNGP06.phx.gbl...

Première des choses, vous ne pouvez pas avoir une table dont la collation
est en Windows-1252. Il y a bien des collations 1250 telles que
SQL_Latin1_General_CP1250_CI_AS mais quand MS a introduit la collaton
1252 afin de tenir compte du symbole Euro, cet ajout ne semble pas avoir
été introduit dans les vieilles collations de compatibilité de
SQL-Server. Cependant, je peux me tromper sur ce point particulier
surtout que pour moi, l'utilisation du symbole Euro n'a pas vraiment
d'importance.

Pour ce qui est du charset par défaut de l'environmment, il n'y a en pas
un mais deux: il y a l'OEM (à ne pas confondre avec la vente de matériel
OEM et les versions OEM de Windows) et la Windows. Certains clients vont
utiliser l'OEM et d'autres (la majorité) la Windows. Pour ceux qui vont
utiliser la Windows, certains vont encoder les caractères et d'autres pas
et parmi ceux qui vont le faire, certains pourront le faire de façon
facultative selon le choix du mode d'affichage utilisé. Même pour ceux
qui ne touchent pas à l'encodage, certains pilotes pourront faire ou non
l'encodage, de façon obligatoire ou facultative seront un paramètre de
configuration. (Cet encodage par les pilotes est une des raisons
majeures pour utiliser le préfixe N' ). Lorsqu'il y a un paramètre de
configuration, ce dernier peut être situé quelquefois dans la chaîne de
connexion; quelquefois dans la base de registres et quelquefois dans les
deux. Il y a aussi les paramètres dans la base de registres pour
d'autres programmes qui peuvent influencer le tout (voilà quelques
années, cela m'a pris plusieurs jours afin de déterminer pourquoi
l'importation à partir de fichiers Excel ne fonctionnait pas correctement
sur les machines sur lesquelles Interbase (la bdd de Borland) avait aussi
été installé avant de trouver qu'Interbase modifiait un paramètre dans la
base de registres pour JET et que la méthode utilisée pour importer les
données à partir d'Excel utilisait JET ODBC.

Vous dites que vous avez toutes les couches intermédiaires pour réaliser
les transcodages nécessaires; j'en suis bien content pour vous! Le
problème est, j'ai déjà appelé en consultation pour régler des problèmes
d'encodages sur des systèmes pour lesquelles le ou les développeurs me
disaient qu'il était impossible qu'il y ait le moindre problème
puisqu'ils avaient supposément toutes les couches nécessaires. S'il est
impossible qu'il y ait un problème, alors pourquoi y en a-t-il un???

La principale raison évoquée pour se casser la tête (et quelquefois les
coui**es) avec l'ANSI sur SQL-Server en est un de performance: on dit
souvent que cela va aller plus vite. Dans la plupart des cas, la
différence est imperceptible ou inutile (la seule différence notable que
je connaisse est avec l'utilisation de l'opérateur LIKE '%xxxx%' et même
là, vous êtes généralement mieux avec l'utilisation d'une deuxième
colonne inversée que de vous fier sur ANSI) et généralement, si vous avez
un problème de performance quelconque, vous êtes mieux d'analyser et de
corriger votre design que de vous fiez sur ANSI à la place d'Unicode.

La seule chose que j'ai vu dans le passé pour ceux qui s'obstinaient à
vouloir conserver l'ANSI à la place d'Unicode a été une perte de temps
(et considérable le plus souvent qu'autrement).

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)


"Pierre Goiffon" <pgoiffon@free.fr.invalid> wrote in message
news:46dd0f06$0$9225$426a74cc@news.free.fr...

Sylvain Lafontaine wrote:

Que celui qui s'oppose à utiliser VARCHAR pour le stockage de texte
uniquement en français parle maintenant ou se taise à jamais !

Tout simplement parce que vous ne pouvez pas garantir que toutes les
personnes accédant à votre base de données auront le même code page
Windows que le serveur SQL; au présent et dans le futur. Prenez pas
exemple une personne vivant en Grèce. Pensez-vous vraiment que son
choix de vie est de toujours avoir un code page français sur sa
machine?

?!!?!!!!!!!
Vous n'avez pas beaucoup développé alors peut être que je rate quelque
chose, mais ce que vous écrivez n'est pas du tout correct !

Un Windows asiatique dont le charset par défaut serait GB-2312 pourra
très bien accéder et afficher les données d'un varchar contenant des
données en français dans une table dont la collation est en windows-1252
!

Il ne faut pas confondre le charset par défaut de l'environnement, le
codage paramétré pour la connexion à la base, et la collation utilisée
sur cette dernière.
On a tous les midleware qui vont bien pour réaliser les transcodages
nécessaires, avec un minimum de compétences et de rigueur cela ne
représente aucun prb.

Donc oui, si l'on a des données uniquement en langues latines, pas
besoin d'utiliser un stockage Unicode.

test windows a écrit :

Bonjour;
j'ai une donnée sql 2005 uniquement en français et je ne vois pas l'interet
de stocker les données en unicode avec le préfixe N..merci

Tout ce qui peut réduire le volume des données contribuera de façon
drastique à améliorer les performances du fait de la limite du cache de
données. Or un NATIONAL CHAR ou NATIONAL VARCHAR, prend de fois plus de
place que'un CHAR ou VARCHAR. En conclusion, si vous n'en avez pas
besoin cela est inutile.

Exemple si votre RAM est de 2 Go, le cache de données devrait être de
l'ordre de 1,5 Go. Si ces 1,5 Go vous permettent de mettre en mémoire 5
000 clients et leurs 50 000 factures en varchar, alors en unicode, vous
en aurez un peu plus de la moitié et votre SGBDR devra donc paginer sur
le dique.

Or la différence de vitesse entre le disque et la ram est de l'ordre
d'un facteur 1000.

A +

--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************

Patrice wrote:

De mon côté, il me parait un peu extrème de préconiser une utilisation
*systématique* de unicode (ou j'ai mal compris) notamment sans que l'OP ait
précisé si c'est une base interne à l'entreprise, destinée à des clients
internationaux etc (à priori il n'envisage d'utiliser que du français et les
"clients" (au sens technique) ne sont pas précisés)...

De plus, le passage en unicode n'est pas spécialement compliqué à faire si
cela devenait réellement nécessaire un jour.

Ici on a les deux en fonction des besoins. Je ne m'"obstine" pas à garder
ANSI. Je préfère simplement choisir la solution la plus logique et donc pas
d'unicode quand je n'en ai aucunement besoin.

Je n'aurai pas dis mieux, merci de cette réponse réfléchie.

On voit à longueur de forum techniques des intervenants utilisant des
solutions systématiquement sans se poser de questions, et un jour bien
bloquer et refuser d'essayer de comprendre... Toute les discussions
relatives aux codages entrent souvent dans ce très mauvais plis...

Je préfère de très loin un développeur qui fait des choix cohérents et
réfléchis, fais en sorte de paramétrer sa connexion ODBC ou OLE-DB
correctement et gère bien le codage jusqu'à l'impression finale, qu'un
autre qui applique une méthode en se disant que c'est très bien comme ça
sans se soucier du besoin !

L'usage généralisé d'Unicode est très séduisant (parmis tous les codages
disponibles, UTF-8 est très répandu et UTF-16 pose de moins en moins de
soucis) mais se heurte encore à de nombreux soucis de compatibilité
(envois par email en particulier), quand ce n'est pas simplement de
volumétrie (passez en UTF-8 un contenu dans une langue est-asiatique,
vous allez rire).

Bref, il est simple et facile de maîtriser le codage de la base de
données au traitement final, alors autant le faire en intelligence. Cela
demande par contre un minimum d'investissement en lecture de doc, comme
toujours. Mais c'est très payant !