Bonour,
Sylvain Lafontaine a écrit :Donc et contrairement à Sylvain lafontaine qui raisonne à courte vue, il
n'est pas raisonnable d'utiliser du NATIONAL (N de CHAR ou VARCHAR
voulant dire NATIONAL) si cela n'est pas nécessaire.
Tiens, c'est bizarre, j'avais exactement le même genre d'idée: ceux qui
utilisent des varchar sans raison valable sont justement ceux qui me
semblent raisonner à courte vue.
Pour le reste, l'utilisation de l'Unicode double la taille des champs
textes mais cela correspond à une augmentation moyenne de 30% de la
taille de la BDD et peut-être à une diminution moyenne de 10% de la
performance. Autrement, avec les machines modernes, une perte de temps
complète que de tracasser à ce sujet là puisqu'une diminution de 10% de
la performance va passer totalement inaperçue chez l'utilisateur; même
s'il essaie de la mesurer avec un chrono.
Pas 30% plutôt 40 car les nombres et date occupent peu de place.
Or 40 % de volume en plus sur une base de 100 Go c'est 180 GO !
Ce qui risque cependant de ne pas passer inaperçue sera les heures, les
journées et les semaines de travail perdu en cas de problème d'encodage.
Je n'ai jamais reçu un appel ou un message de quelqu'un se plaignant de
la légère baisse de performance suite à l'utilisation de l'unicode;
cependant, pour le reste, les problèmes d'encodage pour ceux qui
utilisent l'ascii, c'est comme les taxes: il y en a partout.
C'est curieux car dans les audit que je fais, pour une dizaine d'entre eux
j'ai prouvé de sacré différence de performances par exemple pour réindexer
la base ! On passe tout simplement du simple au presque double...
Mais il est vrai que je doit manquer d'expérience puisque je ne pratique
l'audit de bases de données SQL Server que depuis une quinzaines d'années
!
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
Bonour,
Sylvain Lafontaine a écrit :
Donc et contrairement à Sylvain lafontaine qui raisonne à courte vue, il
n'est pas raisonnable d'utiliser du NATIONAL (N de CHAR ou VARCHAR
voulant dire NATIONAL) si cela n'est pas nécessaire.
Tiens, c'est bizarre, j'avais exactement le même genre d'idée: ceux qui
utilisent des varchar sans raison valable sont justement ceux qui me
semblent raisonner à courte vue.
Pour le reste, l'utilisation de l'Unicode double la taille des champs
textes mais cela correspond à une augmentation moyenne de 30% de la
taille de la BDD et peut-être à une diminution moyenne de 10% de la
performance. Autrement, avec les machines modernes, une perte de temps
complète que de tracasser à ce sujet là puisqu'une diminution de 10% de
la performance va passer totalement inaperçue chez l'utilisateur; même
s'il essaie de la mesurer avec un chrono.
Pas 30% plutôt 40 car les nombres et date occupent peu de place.
Or 40 % de volume en plus sur une base de 100 Go c'est 180 GO !
Ce qui risque cependant de ne pas passer inaperçue sera les heures, les
journées et les semaines de travail perdu en cas de problème d'encodage.
Je n'ai jamais reçu un appel ou un message de quelqu'un se plaignant de
la légère baisse de performance suite à l'utilisation de l'unicode;
cependant, pour le reste, les problèmes d'encodage pour ceux qui
utilisent l'ascii, c'est comme les taxes: il y en a partout.
C'est curieux car dans les audit que je fais, pour une dizaine d'entre eux
j'ai prouvé de sacré différence de performances par exemple pour réindexer
la base ! On passe tout simplement du simple au presque double...
Mais il est vrai que je doit manquer d'expérience puisque je ne pratique
l'audit de bases de données SQL Server que depuis une quinzaines d'années
!
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
Bonour,
Sylvain Lafontaine a écrit :Donc et contrairement à Sylvain lafontaine qui raisonne à courte vue, il
n'est pas raisonnable d'utiliser du NATIONAL (N de CHAR ou VARCHAR
voulant dire NATIONAL) si cela n'est pas nécessaire.
Tiens, c'est bizarre, j'avais exactement le même genre d'idée: ceux qui
utilisent des varchar sans raison valable sont justement ceux qui me
semblent raisonner à courte vue.
Pour le reste, l'utilisation de l'Unicode double la taille des champs
textes mais cela correspond à une augmentation moyenne de 30% de la
taille de la BDD et peut-être à une diminution moyenne de 10% de la
performance. Autrement, avec les machines modernes, une perte de temps
complète que de tracasser à ce sujet là puisqu'une diminution de 10% de
la performance va passer totalement inaperçue chez l'utilisateur; même
s'il essaie de la mesurer avec un chrono.
Pas 30% plutôt 40 car les nombres et date occupent peu de place.
Or 40 % de volume en plus sur une base de 100 Go c'est 180 GO !
Ce qui risque cependant de ne pas passer inaperçue sera les heures, les
journées et les semaines de travail perdu en cas de problème d'encodage.
Je n'ai jamais reçu un appel ou un message de quelqu'un se plaignant de
la légère baisse de performance suite à l'utilisation de l'unicode;
cependant, pour le reste, les problèmes d'encodage pour ceux qui
utilisent l'ascii, c'est comme les taxes: il y en a partout.
C'est curieux car dans les audit que je fais, pour une dizaine d'entre eux
j'ai prouvé de sacré différence de performances par exemple pour réindexer
la base ! On passe tout simplement du simple au presque double...
Mais il est vrai que je doit manquer d'expérience puisque je ne pratique
l'audit de bases de données SQL Server que depuis une quinzaines d'années
!
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
"Fred BROUARD" wrote in message
news:%Bonour,
Sylvain Lafontaine a écrit :Donc et contrairement à Sylvain lafontaine qui raisonne à courte vue, il
n'est pas raisonnable d'utiliser du NATIONAL (N de CHAR ou VARCHAR
voulant dire NATIONAL) si cela n'est pas nécessaire.
Tiens, c'est bizarre, j'avais exactement le même genre d'idée: ceux qui
utilisent des varchar sans raison valable sont justement ceux qui me
semblent raisonner à courte vue.
Pour le reste, l'utilisation de l'Unicode double la taille des champs
textes mais cela correspond à une augmentation moyenne de 30% de la
taille de la BDD et peut-être à une diminution moyenne de 10% de la
performance. Autrement, avec les machines modernes, une perte de temps
complète que de tracasser à ce sujet là puisqu'une diminution de 10% de
la performance va passer totalement inaperçue chez l'utilisateur; même
s'il essaie de la mesurer avec un chrono.
Pas 30% plutôt 40 car les nombres et date occupent peu de place.
Or 40 % de volume en plus sur une base de 100 Go c'est 180 GO !
Premièrement, je ne sais pas comment vous pouvez arriver à 180 Go en
ajoutant 40% à une base 100 Go mais honnêtement, je préfère ne pas
l'apprendre (quoique à vue de nez, vous semblez avoir fait 100 + 40 + 40 =
180). Pour le reste, 30%, 40% ou même si c'était 50% de plus, qu'est-ce que
cela change?
Pour la très grande majorité des utilisateurs, cela veut tout
simplement dire un peu moins d'espace vide sur leur disque dur. Pour les
quelques autres qui restent, ceux qui ont déjà un disque dur presque plein,
j'imagine que de tout façon, ils devront s'acheter un nouveau disque dur
avant longtemps si leur système est déjà proche de la saturation.
Ce qui risque cependant de ne pas passer inaperçue sera les heures, les
journées et les semaines de travail perdu en cas de problème d'encodage.
Je n'ai jamais reçu un appel ou un message de quelqu'un se plaignant de
la légère baisse de performance suite à l'utilisation de l'unicode;
cependant, pour le reste, les problèmes d'encodage pour ceux qui
utilisent l'ascii, c'est comme les taxes: il y en a partout.
C'est curieux car dans les audit que je fais, pour une dizaine d'entre eux
j'ai prouvé de sacré différence de performances par exemple pour réindexer
la base ! On passe tout simplement du simple au presque double...
Je suis d'accord avec vous que la réindexation est très lourde sur les E/S
(ou I/O en anglais) mais à moins que vos utilisateurs ne passent leur
journée à réindexer leur dbb, qu'est-ce que change ou importe?
Tant qu'à
moi, le fait que la réindexation puisse prendre le double du temps ne pèse
vraiment pas lourd dans la balance.
Mais bon, vous semblez être ce genre de
personne qui se promène avec un chrono à la main comme si cela était la plus
importante des choses.
Peut-être que vos clients sont super-impressionnés par le fait que la
réindexation puisse prendre le double du temps mais en ce qui me concerne,
vous n'irez pas bien loin avec cela comme argument.
Mais il est vrai que je doit manquer d'expérience puisque je ne pratique
l'audit de bases de données SQL Server que depuis une quinzaines d'années
!
Et bien dans ce cas-là, vous devriez savoir que l'on est maintenant rendu en
2009 et non plus en 1996. Les ordinateurs ont évolué depuis quinze ans. La
puissance des machines double à tous les 18 mois;
le passage de l'ascii à
l'unicode correspond donc à l'équivalent de quelques mois. Je ne pense pas
que vous avez jamais dit à un client qu'il devait attendre quelques mois
avant d'acheter son nouveau système parce que sinon, il serait trop lent.
À mons avis, vous devriez arrêter de perdre votre temps avec votre chrono;
il y a des choses plus importantes dans la vie que de s'intéresser à un 10,
20 ou 30% de puissance d'un CPU ou d'une barrette de mémoire.
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
"Fred BROUARD" <brouardf@club-internet.fr> wrote in message
news:%23eligjiPKHA.4208@TK2MSFTNGP05.phx.gbl...
Bonour,
Sylvain Lafontaine a écrit :
Donc et contrairement à Sylvain lafontaine qui raisonne à courte vue, il
n'est pas raisonnable d'utiliser du NATIONAL (N de CHAR ou VARCHAR
voulant dire NATIONAL) si cela n'est pas nécessaire.
Tiens, c'est bizarre, j'avais exactement le même genre d'idée: ceux qui
utilisent des varchar sans raison valable sont justement ceux qui me
semblent raisonner à courte vue.
Pour le reste, l'utilisation de l'Unicode double la taille des champs
textes mais cela correspond à une augmentation moyenne de 30% de la
taille de la BDD et peut-être à une diminution moyenne de 10% de la
performance. Autrement, avec les machines modernes, une perte de temps
complète que de tracasser à ce sujet là puisqu'une diminution de 10% de
la performance va passer totalement inaperçue chez l'utilisateur; même
s'il essaie de la mesurer avec un chrono.
Pas 30% plutôt 40 car les nombres et date occupent peu de place.
Or 40 % de volume en plus sur une base de 100 Go c'est 180 GO !
Premièrement, je ne sais pas comment vous pouvez arriver à 180 Go en
ajoutant 40% à une base 100 Go mais honnêtement, je préfère ne pas
l'apprendre (quoique à vue de nez, vous semblez avoir fait 100 + 40 + 40 =
180). Pour le reste, 30%, 40% ou même si c'était 50% de plus, qu'est-ce que
cela change?
Pour la très grande majorité des utilisateurs, cela veut tout
simplement dire un peu moins d'espace vide sur leur disque dur. Pour les
quelques autres qui restent, ceux qui ont déjà un disque dur presque plein,
j'imagine que de tout façon, ils devront s'acheter un nouveau disque dur
avant longtemps si leur système est déjà proche de la saturation.
Ce qui risque cependant de ne pas passer inaperçue sera les heures, les
journées et les semaines de travail perdu en cas de problème d'encodage.
Je n'ai jamais reçu un appel ou un message de quelqu'un se plaignant de
la légère baisse de performance suite à l'utilisation de l'unicode;
cependant, pour le reste, les problèmes d'encodage pour ceux qui
utilisent l'ascii, c'est comme les taxes: il y en a partout.
C'est curieux car dans les audit que je fais, pour une dizaine d'entre eux
j'ai prouvé de sacré différence de performances par exemple pour réindexer
la base ! On passe tout simplement du simple au presque double...
Je suis d'accord avec vous que la réindexation est très lourde sur les E/S
(ou I/O en anglais) mais à moins que vos utilisateurs ne passent leur
journée à réindexer leur dbb, qu'est-ce que change ou importe?
Tant qu'à
moi, le fait que la réindexation puisse prendre le double du temps ne pèse
vraiment pas lourd dans la balance.
Mais bon, vous semblez être ce genre de
personne qui se promène avec un chrono à la main comme si cela était la plus
importante des choses.
Peut-être que vos clients sont super-impressionnés par le fait que la
réindexation puisse prendre le double du temps mais en ce qui me concerne,
vous n'irez pas bien loin avec cela comme argument.
Mais il est vrai que je doit manquer d'expérience puisque je ne pratique
l'audit de bases de données SQL Server que depuis une quinzaines d'années
!
Et bien dans ce cas-là, vous devriez savoir que l'on est maintenant rendu en
2009 et non plus en 1996. Les ordinateurs ont évolué depuis quinze ans. La
puissance des machines double à tous les 18 mois;
le passage de l'ascii à
l'unicode correspond donc à l'équivalent de quelques mois. Je ne pense pas
que vous avez jamais dit à un client qu'il devait attendre quelques mois
avant d'acheter son nouveau système parce que sinon, il serait trop lent.
À mons avis, vous devriez arrêter de perdre votre temps avec votre chrono;
il y a des choses plus importantes dans la vie que de s'intéresser à un 10,
20 ou 30% de puissance d'un CPU ou d'une barrette de mémoire.
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
"Fred BROUARD" wrote in message
news:%Bonour,
Sylvain Lafontaine a écrit :Donc et contrairement à Sylvain lafontaine qui raisonne à courte vue, il
n'est pas raisonnable d'utiliser du NATIONAL (N de CHAR ou VARCHAR
voulant dire NATIONAL) si cela n'est pas nécessaire.
Tiens, c'est bizarre, j'avais exactement le même genre d'idée: ceux qui
utilisent des varchar sans raison valable sont justement ceux qui me
semblent raisonner à courte vue.
Pour le reste, l'utilisation de l'Unicode double la taille des champs
textes mais cela correspond à une augmentation moyenne de 30% de la
taille de la BDD et peut-être à une diminution moyenne de 10% de la
performance. Autrement, avec les machines modernes, une perte de temps
complète que de tracasser à ce sujet là puisqu'une diminution de 10% de
la performance va passer totalement inaperçue chez l'utilisateur; même
s'il essaie de la mesurer avec un chrono.
Pas 30% plutôt 40 car les nombres et date occupent peu de place.
Or 40 % de volume en plus sur une base de 100 Go c'est 180 GO !
Premièrement, je ne sais pas comment vous pouvez arriver à 180 Go en
ajoutant 40% à une base 100 Go mais honnêtement, je préfère ne pas
l'apprendre (quoique à vue de nez, vous semblez avoir fait 100 + 40 + 40 =
180). Pour le reste, 30%, 40% ou même si c'était 50% de plus, qu'est-ce que
cela change?
Pour la très grande majorité des utilisateurs, cela veut tout
simplement dire un peu moins d'espace vide sur leur disque dur. Pour les
quelques autres qui restent, ceux qui ont déjà un disque dur presque plein,
j'imagine que de tout façon, ils devront s'acheter un nouveau disque dur
avant longtemps si leur système est déjà proche de la saturation.
Ce qui risque cependant de ne pas passer inaperçue sera les heures, les
journées et les semaines de travail perdu en cas de problème d'encodage.
Je n'ai jamais reçu un appel ou un message de quelqu'un se plaignant de
la légère baisse de performance suite à l'utilisation de l'unicode;
cependant, pour le reste, les problèmes d'encodage pour ceux qui
utilisent l'ascii, c'est comme les taxes: il y en a partout.
C'est curieux car dans les audit que je fais, pour une dizaine d'entre eux
j'ai prouvé de sacré différence de performances par exemple pour réindexer
la base ! On passe tout simplement du simple au presque double...
Je suis d'accord avec vous que la réindexation est très lourde sur les E/S
(ou I/O en anglais) mais à moins que vos utilisateurs ne passent leur
journée à réindexer leur dbb, qu'est-ce que change ou importe?
Tant qu'à
moi, le fait que la réindexation puisse prendre le double du temps ne pèse
vraiment pas lourd dans la balance.
Mais bon, vous semblez être ce genre de
personne qui se promène avec un chrono à la main comme si cela était la plus
importante des choses.
Peut-être que vos clients sont super-impressionnés par le fait que la
réindexation puisse prendre le double du temps mais en ce qui me concerne,
vous n'irez pas bien loin avec cela comme argument.
Mais il est vrai que je doit manquer d'expérience puisque je ne pratique
l'audit de bases de données SQL Server que depuis une quinzaines d'années
!
Et bien dans ce cas-là, vous devriez savoir que l'on est maintenant rendu en
2009 et non plus en 1996. Les ordinateurs ont évolué depuis quinze ans. La
puissance des machines double à tous les 18 mois;
le passage de l'ascii à
l'unicode correspond donc à l'équivalent de quelques mois. Je ne pense pas
que vous avez jamais dit à un client qu'il devait attendre quelques mois
avant d'acheter son nouveau système parce que sinon, il serait trop lent.
À mons avis, vous devriez arrêter de perdre votre temps avec votre chrono;
il y a des choses plus importantes dans la vie que de s'intéresser à un 10,
20 ou 30% de puissance d'un CPU ou d'une barrette de mémoire.
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
Bonjour,
Sylvain Lafontaine a écrit :
visiblement vous avez du mal avec les math :
180 * 0,4 = 72
donc la base sans ces NATIONAL ferait quelque 108 Go...
Quand on parle en pourcentage on parle à partir d'un tout...
Visiblement vous ne savez pas comment fonctionne un SGBDR. Un SGBDR
travaille presque exclusivement avec la RAM. Le disque est un épiphénomène
destiné à assurer une seule fonction : celle de la persistance des
données.
Le jour ou les mémoires ne seront plus volatile (et il est proche avec les
SSD), il n'y aura plus de disque.
Or le disque freine énormément les performances. Entre une lecture disque
environ 9 ns et une lecture disque environ 9 ms, il y a un écart
intrinsèque de 1 millions !
Dans la pratique, compte tenu des bus et des caches, on parle d'un rapport
d'au moins 1000 !
Or la RAM coûte cher et vous n'allez certainement pas dire à votre client
rajoutez donc 80 Go de RAM pour assumer votre lubie inutile d'unicode !
Allez dire à mes clients ce genre de choses et ils vont vous rirent au nez
!!!
Vous dites vraiment n'importe quoi. Permettez moi de vous inviter à suivre
un cours. N'hésitez pas à vous inscrire au CNAM PACA ou je donne le cours
NFE 113 sur la modélisation des données et l'administration des serveurs,
c'est justement le cœur du sujet !
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
Bonjour,
Sylvain Lafontaine a écrit :
visiblement vous avez du mal avec les math :
180 * 0,4 = 72
donc la base sans ces NATIONAL ferait quelque 108 Go...
Quand on parle en pourcentage on parle à partir d'un tout...
Visiblement vous ne savez pas comment fonctionne un SGBDR. Un SGBDR
travaille presque exclusivement avec la RAM. Le disque est un épiphénomène
destiné à assurer une seule fonction : celle de la persistance des
données.
Le jour ou les mémoires ne seront plus volatile (et il est proche avec les
SSD), il n'y aura plus de disque.
Or le disque freine énormément les performances. Entre une lecture disque
environ 9 ns et une lecture disque environ 9 ms, il y a un écart
intrinsèque de 1 millions !
Dans la pratique, compte tenu des bus et des caches, on parle d'un rapport
d'au moins 1000 !
Or la RAM coûte cher et vous n'allez certainement pas dire à votre client
rajoutez donc 80 Go de RAM pour assumer votre lubie inutile d'unicode !
Allez dire à mes clients ce genre de choses et ils vont vous rirent au nez
!!!
Vous dites vraiment n'importe quoi. Permettez moi de vous inviter à suivre
un cours. N'hésitez pas à vous inscrire au CNAM PACA ou je donne le cours
NFE 113 sur la modélisation des données et l'administration des serveurs,
c'est justement le cœur du sujet !
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
Bonjour,
Sylvain Lafontaine a écrit :
visiblement vous avez du mal avec les math :
180 * 0,4 = 72
donc la base sans ces NATIONAL ferait quelque 108 Go...
Quand on parle en pourcentage on parle à partir d'un tout...
Visiblement vous ne savez pas comment fonctionne un SGBDR. Un SGBDR
travaille presque exclusivement avec la RAM. Le disque est un épiphénomène
destiné à assurer une seule fonction : celle de la persistance des
données.
Le jour ou les mémoires ne seront plus volatile (et il est proche avec les
SSD), il n'y aura plus de disque.
Or le disque freine énormément les performances. Entre une lecture disque
environ 9 ns et une lecture disque environ 9 ms, il y a un écart
intrinsèque de 1 millions !
Dans la pratique, compte tenu des bus et des caches, on parle d'un rapport
d'au moins 1000 !
Or la RAM coûte cher et vous n'allez certainement pas dire à votre client
rajoutez donc 80 Go de RAM pour assumer votre lubie inutile d'unicode !
Allez dire à mes clients ce genre de choses et ils vont vous rirent au nez
!!!
Vous dites vraiment n'importe quoi. Permettez moi de vous inviter à suivre
un cours. N'hésitez pas à vous inscrire au CNAM PACA ou je donne le cours
NFE 113 sur la modélisation des données et l'administration des serveurs,
c'est justement le cœur du sujet !
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
Je ne sais pas s'ils vont me rire au nez mais je peux vous dire que quand
quelqu'un vous appelle pour dire qu'il se retrouve avec un problème
d'encodage dans sa bdd, il se met à rire jaune entre ses dents quand il
apprend qu'il n'y a pas de solution non-coûteuse pour corriger son problème
et quand plus, même après avoir corrigé le problème, il risque fort de
rester avec des données corrompues pour les données déjà entrées.
Je ne sais pas s'ils vont me rire au nez mais je peux vous dire que quand
quelqu'un vous appelle pour dire qu'il se retrouve avec un problème
d'encodage dans sa bdd, il se met à rire jaune entre ses dents quand il
apprend qu'il n'y a pas de solution non-coûteuse pour corriger son problème
et quand plus, même après avoir corrigé le problème, il risque fort de
rester avec des données corrompues pour les données déjà entrées.
Je ne sais pas s'ils vont me rire au nez mais je peux vous dire que quand
quelqu'un vous appelle pour dire qu'il se retrouve avec un problème
d'encodage dans sa bdd, il se met à rire jaune entre ses dents quand il
apprend qu'il n'y a pas de solution non-coûteuse pour corriger son problème
et quand plus, même après avoir corrigé le problème, il risque fort de
rester avec des données corrompues pour les données déjà entrées.
Sylvain Lafontaine wrote:Je ne sais pas s'ils vont me rire au nez mais je peux vous dire que quand
quelqu'un vous appelle pour dire qu'il se retrouve avec un problème
d'encodage dans sa bdd, il se met à rire jaune entre ses dents quand il
apprend qu'il n'y a pas de solution non-coûteuse pour corriger son
problème et quand plus, même après avoir corrigé le problème, il risque
fort de rester avec des données corrompues pour les données déjà entrées.
Bonjour,
J'ai lu ce fil avec intérêt. J'ai beaucoup de questions en tête... Car pas
les idées très claires sur le sujet. Je précise que j'ai massivement
développé avec SQL Server 7 et 2000, mais que je n'y ai depuis 5 ans
touché qu'à (malheureusement) grande distance.
D'abord une réflexion qui me vient rapidement en lisant vos arguments : il
est quand même très répandu par ici qu'une base ne stocke que des données
en scripts latins. Utiliser Unicode dans ce cas est plutôt "overkill",
même avec les machines d'aujourd'hui ! Car nous parlons bien de serveur de
bdd d'entreprise, pour lesquels ont essaie de tenir le plus juste
compromis, qui sont donc des machines puissantes mais que l'on a choisit
pour les exploiter à leur plus juste potentiel.
Bref, si passer à un stockage tout Unicode n'avait aucune conséquence sur
la consommation de ressources, ok, mais ce n'est pas du tout le cas
(retour de Fred et de nombreux collègues sur le sujet). Se poser la
question me parait donc être un minimum. A voir ensuite suivant le
contexte particulier pour prendre sa décision...
Pour les questions : je ne comprend pas le lien entre collation et champs
nchar / nvarchar ? Il n'existe pas de collation assurant un stockage en
Unicode, Utf-8 ou 16 ? On doit donc définir une certaine collation sur un
charset 8 bits, et utiliser des champs nchar / nvarchar si l'on souhaite
stocker des données dans plusieurs scripts ?
Ensuite, comment gérer les autres critères de la collation (tri,
comparaison) lorsque l'on a dans une même colonne des données dans de
nombreux scripts ? Par exemple, peut-on obtenir un ordre de tri pour telle
famille de scripts, tel autre pour un autre, ... Ou faut-il alors plutôt
envisager un stockage dans une table par collation ? Dans ce cas, quel est
l'intérêt dans la réalité d'un champ nchar / nvarchar ?
Sylvain Lafontaine wrote:
Je ne sais pas s'ils vont me rire au nez mais je peux vous dire que quand
quelqu'un vous appelle pour dire qu'il se retrouve avec un problème
d'encodage dans sa bdd, il se met à rire jaune entre ses dents quand il
apprend qu'il n'y a pas de solution non-coûteuse pour corriger son
problème et quand plus, même après avoir corrigé le problème, il risque
fort de rester avec des données corrompues pour les données déjà entrées.
Bonjour,
J'ai lu ce fil avec intérêt. J'ai beaucoup de questions en tête... Car pas
les idées très claires sur le sujet. Je précise que j'ai massivement
développé avec SQL Server 7 et 2000, mais que je n'y ai depuis 5 ans
touché qu'à (malheureusement) grande distance.
D'abord une réflexion qui me vient rapidement en lisant vos arguments : il
est quand même très répandu par ici qu'une base ne stocke que des données
en scripts latins. Utiliser Unicode dans ce cas est plutôt "overkill",
même avec les machines d'aujourd'hui ! Car nous parlons bien de serveur de
bdd d'entreprise, pour lesquels ont essaie de tenir le plus juste
compromis, qui sont donc des machines puissantes mais que l'on a choisit
pour les exploiter à leur plus juste potentiel.
Bref, si passer à un stockage tout Unicode n'avait aucune conséquence sur
la consommation de ressources, ok, mais ce n'est pas du tout le cas
(retour de Fred et de nombreux collègues sur le sujet). Se poser la
question me parait donc être un minimum. A voir ensuite suivant le
contexte particulier pour prendre sa décision...
Pour les questions : je ne comprend pas le lien entre collation et champs
nchar / nvarchar ? Il n'existe pas de collation assurant un stockage en
Unicode, Utf-8 ou 16 ? On doit donc définir une certaine collation sur un
charset 8 bits, et utiliser des champs nchar / nvarchar si l'on souhaite
stocker des données dans plusieurs scripts ?
Ensuite, comment gérer les autres critères de la collation (tri,
comparaison) lorsque l'on a dans une même colonne des données dans de
nombreux scripts ? Par exemple, peut-on obtenir un ordre de tri pour telle
famille de scripts, tel autre pour un autre, ... Ou faut-il alors plutôt
envisager un stockage dans une table par collation ? Dans ce cas, quel est
l'intérêt dans la réalité d'un champ nchar / nvarchar ?
Sylvain Lafontaine wrote:Je ne sais pas s'ils vont me rire au nez mais je peux vous dire que quand
quelqu'un vous appelle pour dire qu'il se retrouve avec un problème
d'encodage dans sa bdd, il se met à rire jaune entre ses dents quand il
apprend qu'il n'y a pas de solution non-coûteuse pour corriger son
problème et quand plus, même après avoir corrigé le problème, il risque
fort de rester avec des données corrompues pour les données déjà entrées.
Bonjour,
J'ai lu ce fil avec intérêt. J'ai beaucoup de questions en tête... Car pas
les idées très claires sur le sujet. Je précise que j'ai massivement
développé avec SQL Server 7 et 2000, mais que je n'y ai depuis 5 ans
touché qu'à (malheureusement) grande distance.
D'abord une réflexion qui me vient rapidement en lisant vos arguments : il
est quand même très répandu par ici qu'une base ne stocke que des données
en scripts latins. Utiliser Unicode dans ce cas est plutôt "overkill",
même avec les machines d'aujourd'hui ! Car nous parlons bien de serveur de
bdd d'entreprise, pour lesquels ont essaie de tenir le plus juste
compromis, qui sont donc des machines puissantes mais que l'on a choisit
pour les exploiter à leur plus juste potentiel.
Bref, si passer à un stockage tout Unicode n'avait aucune conséquence sur
la consommation de ressources, ok, mais ce n'est pas du tout le cas
(retour de Fred et de nombreux collègues sur le sujet). Se poser la
question me parait donc être un minimum. A voir ensuite suivant le
contexte particulier pour prendre sa décision...
Pour les questions : je ne comprend pas le lien entre collation et champs
nchar / nvarchar ? Il n'existe pas de collation assurant un stockage en
Unicode, Utf-8 ou 16 ? On doit donc définir une certaine collation sur un
charset 8 bits, et utiliser des champs nchar / nvarchar si l'on souhaite
stocker des données dans plusieurs scripts ?
Ensuite, comment gérer les autres critères de la collation (tri,
comparaison) lorsque l'on a dans une même colonne des données dans de
nombreux scripts ? Par exemple, peut-on obtenir un ordre de tri pour telle
famille de scripts, tel autre pour un autre, ... Ou faut-il alors plutôt
envisager un stockage dans une table par collation ? Dans ce cas, quel est
l'intérêt dans la réalité d'un champ nchar / nvarchar ?
D'abord une réflexion qui me vient rapidement en lisant vos arguments : il
est quand même très répandu par ici qu'une base ne stocke que des données
en scripts latins. Utiliser Unicode dans ce cas est plutôt "overkill"
Même si vous ne stocker que des scripts latins et excluant par le fait tout
caractère étranger (grec, russe, etc.), vous pouvez quand même être frappé
par un problème d'encodage dû à un problème de communication avec une
application client et c'est quelque chose que j'ai vu souvent par le passé.
Le problème c'est que c'est bien souvent loin d'être le cas. Par example,
il y a deux codepages par machine windows: l'OEM, qui correspond au codepage
DOS classique et le codepage Windows.
Évidemment, ils y a ceux qui gèrent de très gros systèmes et pour qui le
passage à l'unicode peut représenter une augmentation significative de coûts
parce que leur système travaille déjà à saturation et qu'ils ne prévoient
pas avoir à supporter autre chose que le français dans un avenir
prévisible - ou qu'ils s'en foutent de ne pas supporter autre chose même si
cela pourrait leur être avantageux - et qu'ils ne prévoient pas interfacer
avec autre chose que des applications-clients ayant strictement le même
codepage qu'eux. Pour eux, cela peut être une décision raisonnable ou un
risque calculé que de s'en tenir au code Ascii. Cependant, s'ils se
trompent, les économies réalisées au début vont fondre plus vite que neige
au soleil et ils risquent de regretter amèrement leur décision par la suite.
C'est pourquoi, avant de prendre cette décision, il faut vraiment savoir où
l'on s'en va et ne pas regarder la question uniquement sous l'aspect
économie de CPU/barrette de mémoire/espace disque. La puissance des
machines double à tous les 18 mois; le coût du programmeur, lui, ne diminue
pas. En fait, dans le cas du programmeur, c'est le contraire qui se passe:
s'il y a une erreur dans le choix de l'Ascii/Unicode, plus vous aller
attendre longtemps avant de corriger l'erreur, plus elle va vous coûter cher
à corriger.
Pour les questions : je ne comprend pas le lien entre collation et champs
nchar / nvarchar ?
La collation n'est pas associée au stockage des caractères mais à leur
interprétation: tri ou/et égalité de caractères
avec comme résultat:
cote
coté
côte
côté
ce qui est incorrect en français standard. D'autres languages utilisant
l'alphabet latins ont des règles de tri et d'équivalence beaucoup plus
complexes que le français, l'allemand ou l'espagnol.
Ensuite, comment gérer les autres critères de la collation (tri,
comparaison) lorsque l'on a dans une même colonne des données dans de
nombreux scripts ? Par exemple, peut-on obtenir un ordre de tri pour telle
famille de scripts, tel autre pour un autre, ... Ou faut-il alors plutôt
envisager un stockage dans une table par collation ? Dans ce cas, quel est
l'intérêt dans la réalité d'un champ nchar / nvarchar ?
D'abord une réflexion qui me vient rapidement en lisant vos arguments : il
est quand même très répandu par ici qu'une base ne stocke que des données
en scripts latins. Utiliser Unicode dans ce cas est plutôt "overkill"
Même si vous ne stocker que des scripts latins et excluant par le fait tout
caractère étranger (grec, russe, etc.), vous pouvez quand même être frappé
par un problème d'encodage dû à un problème de communication avec une
application client et c'est quelque chose que j'ai vu souvent par le passé.
Le problème c'est que c'est bien souvent loin d'être le cas. Par example,
il y a deux codepages par machine windows: l'OEM, qui correspond au codepage
DOS classique et le codepage Windows.
Évidemment, ils y a ceux qui gèrent de très gros systèmes et pour qui le
passage à l'unicode peut représenter une augmentation significative de coûts
parce que leur système travaille déjà à saturation et qu'ils ne prévoient
pas avoir à supporter autre chose que le français dans un avenir
prévisible - ou qu'ils s'en foutent de ne pas supporter autre chose même si
cela pourrait leur être avantageux - et qu'ils ne prévoient pas interfacer
avec autre chose que des applications-clients ayant strictement le même
codepage qu'eux. Pour eux, cela peut être une décision raisonnable ou un
risque calculé que de s'en tenir au code Ascii. Cependant, s'ils se
trompent, les économies réalisées au début vont fondre plus vite que neige
au soleil et ils risquent de regretter amèrement leur décision par la suite.
C'est pourquoi, avant de prendre cette décision, il faut vraiment savoir où
l'on s'en va et ne pas regarder la question uniquement sous l'aspect
économie de CPU/barrette de mémoire/espace disque. La puissance des
machines double à tous les 18 mois; le coût du programmeur, lui, ne diminue
pas. En fait, dans le cas du programmeur, c'est le contraire qui se passe:
s'il y a une erreur dans le choix de l'Ascii/Unicode, plus vous aller
attendre longtemps avant de corriger l'erreur, plus elle va vous coûter cher
à corriger.
Pour les questions : je ne comprend pas le lien entre collation et champs
nchar / nvarchar ?
La collation n'est pas associée au stockage des caractères mais à leur
interprétation: tri ou/et égalité de caractères
avec comme résultat:
cote
coté
côte
côté
ce qui est incorrect en français standard. D'autres languages utilisant
l'alphabet latins ont des règles de tri et d'équivalence beaucoup plus
complexes que le français, l'allemand ou l'espagnol.
Ensuite, comment gérer les autres critères de la collation (tri,
comparaison) lorsque l'on a dans une même colonne des données dans de
nombreux scripts ? Par exemple, peut-on obtenir un ordre de tri pour telle
famille de scripts, tel autre pour un autre, ... Ou faut-il alors plutôt
envisager un stockage dans une table par collation ? Dans ce cas, quel est
l'intérêt dans la réalité d'un champ nchar / nvarchar ?
D'abord une réflexion qui me vient rapidement en lisant vos arguments : il
est quand même très répandu par ici qu'une base ne stocke que des données
en scripts latins. Utiliser Unicode dans ce cas est plutôt "overkill"
Même si vous ne stocker que des scripts latins et excluant par le fait tout
caractère étranger (grec, russe, etc.), vous pouvez quand même être frappé
par un problème d'encodage dû à un problème de communication avec une
application client et c'est quelque chose que j'ai vu souvent par le passé.
Le problème c'est que c'est bien souvent loin d'être le cas. Par example,
il y a deux codepages par machine windows: l'OEM, qui correspond au codepage
DOS classique et le codepage Windows.
Évidemment, ils y a ceux qui gèrent de très gros systèmes et pour qui le
passage à l'unicode peut représenter une augmentation significative de coûts
parce que leur système travaille déjà à saturation et qu'ils ne prévoient
pas avoir à supporter autre chose que le français dans un avenir
prévisible - ou qu'ils s'en foutent de ne pas supporter autre chose même si
cela pourrait leur être avantageux - et qu'ils ne prévoient pas interfacer
avec autre chose que des applications-clients ayant strictement le même
codepage qu'eux. Pour eux, cela peut être une décision raisonnable ou un
risque calculé que de s'en tenir au code Ascii. Cependant, s'ils se
trompent, les économies réalisées au début vont fondre plus vite que neige
au soleil et ils risquent de regretter amèrement leur décision par la suite.
C'est pourquoi, avant de prendre cette décision, il faut vraiment savoir où
l'on s'en va et ne pas regarder la question uniquement sous l'aspect
économie de CPU/barrette de mémoire/espace disque. La puissance des
machines double à tous les 18 mois; le coût du programmeur, lui, ne diminue
pas. En fait, dans le cas du programmeur, c'est le contraire qui se passe:
s'il y a une erreur dans le choix de l'Ascii/Unicode, plus vous aller
attendre longtemps avant de corriger l'erreur, plus elle va vous coûter cher
à corriger.
Pour les questions : je ne comprend pas le lien entre collation et champs
nchar / nvarchar ?
La collation n'est pas associée au stockage des caractères mais à leur
interprétation: tri ou/et égalité de caractères
avec comme résultat:
cote
coté
côte
côté
ce qui est incorrect en français standard. D'autres languages utilisant
l'alphabet latins ont des règles de tri et d'équivalence beaucoup plus
complexes que le français, l'allemand ou l'espagnol.
Ensuite, comment gérer les autres critères de la collation (tri,
comparaison) lorsque l'on a dans une même colonne des données dans de
nombreux scripts ? Par exemple, peut-on obtenir un ordre de tri pour telle
famille de scripts, tel autre pour un autre, ... Ou faut-il alors plutôt
envisager un stockage dans une table par collation ? Dans ce cas, quel est
l'intérêt dans la réalité d'un champ nchar / nvarchar ?
Sylvain Lafontaine wrote:D'abord une réflexion qui me vient rapidement en lisant vos arguments
: il est quand même très répandu par ici qu'une base ne stocke que
des données en scripts latins. Utiliser Unicode dans ce cas est
plutôt "overkill"
Même si vous ne stocker que des scripts latins et excluant par le fait
tout caractère étranger (grec, russe, etc.), vous pouvez quand même
être frappé par un problème d'encodage dû à un problème de
communication avec une application client et c'est quelque chose que
j'ai vu souvent par le passé.
(...)Le problème c'est que c'est bien souvent loin d'être le cas. Par
example, il y a deux codepages par machine windows: l'OEM, qui
correspond au codepage DOS classique et le codepage Windows.
Je ne comprend pas cet argument : dans tous les cas, vous devez
contrôler ces 2 points :
- stockage dans la base de données
- charset utilisé par l'application client dans sa connexion à la BDD
+ tout le reste de la chaine jusqu'à la couche présentation...
Tout passer en Unicode ne permet pas de s'affranchir de cela, ou quelque
chose m'échappe ?!!??
Les notions de codage sont la plupart du temps survolées par les
développeurs, qui se disent "j'ai lu qu'il fallait passer en Unicode
pour résoudre le prb" et ne cherchent pas à aller plus loin. Résoudre un
prb sans comprendre sa cause et avec une manip dont on ne saisit pas les
tenants et aboutissants me parait plus que dangereux !
Mais je vous ai peut être mal compris ?Évidemment, ils y a ceux qui gèrent de très gros systèmes et pour qui
le passage à l'unicode peut représenter une augmentation significative
de coûts parce que leur système travaille déjà à saturation et qu'ils
ne prévoient pas avoir à supporter autre chose que le français dans un
avenir prévisible - ou qu'ils s'en foutent de ne pas supporter autre
chose même si cela pourrait leur être avantageux - et qu'ils ne
prévoient pas interfacer avec autre chose que des applications-clients
ayant strictement le même codepage qu'eux. Pour eux, cela peut être
une décision raisonnable ou un risque calculé que de s'en tenir au
code Ascii. Cependant, s'ils se trompent, les économies réalisées au
début vont fondre plus vite que neige au soleil et ils risquent de
regretter amèrement leur décision par la suite. C'est pourquoi, avant
de prendre cette décision, il faut vraiment savoir où l'on s'en va et
ne pas regarder la question uniquement sous l'aspect économie de
CPU/barrette de mémoire/espace disque. La puissance des machines
double à tous les 18 mois; le coût du programmeur, lui, ne diminue
pas. En fait, dans le cas du programmeur, c'est le contraire qui se
passe: s'il y a une erreur dans le choix de l'Ascii/Unicode, plus vous
aller attendre longtemps avant de corriger l'erreur, plus elle va vous
coûter cher à corriger.
Trois choses après vous avoir lu :
- Des serveurs SQL Server qui sont dimensionné au plus juste, de mon
expérience c'est le cas très largement général... Les machines sont de
plus en plus puissantes, mais les consommations suivent très fidèlement
cette courbe de croissance : en 12 ans d'expérience professionnelle, je
vois toujours autant de prb de performance.
- Si je parlais de scripts latins, c'était pour faire référence à ISO
Latin-9 (iso 8859-15) ou Windows-1252, deux charset 8 bits qui
permettent de stocker toutes les langues d'Europe de l'Ouest. Donc bien
plus que le seul français ! Et on ne peut quand même dire sans se
tromper que la plupart des applications par chez nous (dans les
entreprises françaises) n'ont pas à stocker bien plus... Mais je vous
rejoins évidemment sur le choix à la conception, qui doit être bien
raisonné !
Par ailleurs, parler comme vous le faite "d'ASCII", qui fait en général
référence à us-ascii et donc un charset 7 bits, porte donc assez à
confusion.
- Corriger l'erreur : cela fait partie de mes interrogations... Si l'on
a à modifier le stockage d'une bdd SQL Server vers de l'Unicode,
qu'est-ce que cela va impliquer comme opération ? N'est-ce pas une
"simple" conversion, qui va juste entraîner un arrêt de service le temps
qu'elle prendra ? Les contenus précédents pouvant être recodés en
Unicode, et les anciennes applications clientes se connectant toujours
avec le charset précédent. (pas compris pourquoi vous parliez de "2
versions" ?)
C'est aussi entre autre pourquoi je ne comprend pas la différence entre
ces champs nchar et la collation... on y arrive juste en-dessous.Pour les questions : je ne comprend pas le lien entre collation et
champs nchar / nvarchar ?
La collation n'est pas associée au stockage des caractères mais à leur
interprétation: tri ou/et égalité de caractères
De ce que j'en avais retenu la collation en bdd regroupait les 3 notions :
- codage au stockage
- comparaison
- tri
Par quel paramètre indique-t-on alors dans quel codage stocker les
champs textes char, varchar ? Est-ce figé à un codage non modifiable, ce
qui expliquerait l'existence de ces nchar et nvarchar ? Donc le choix
entre un codage par défaut ou Unicode ? (que je suppose être UTF-16 ?)
Je viens de revérifier, il y avait bien des noms laissant à penser à des
codage dans les collation sur SQL Server 2000 : sur
http://msdn.microsoft.com/en-us/library/aa226047%28SQL.80%29.aspx par
exemple Latin1_General est marqué comme stocké en "1252" (ce qui laisse
à penser qu'il s'agit de Windows-1252)
(...)avec comme résultat:
cote
coté
côte
côté
ce qui est incorrect en français standard. D'autres languages
utilisant l'alphabet latins ont des règles de tri et d'équivalence
beaucoup plus complexes que le français, l'allemand ou l'espagnol.
C'était exactement le sens de ma question :Ensuite, comment gérer les autres critères de la collation (tri,
comparaison) lorsque l'on a dans une même colonne des données dans de
nombreux scripts ? Par exemple, peut-on obtenir un ordre de tri pour
telle famille de scripts, tel autre pour un autre, ... Ou faut-il
alors plutôt envisager un stockage dans une table par collation ?
Dans ce cas, quel est l'intérêt dans la réalité d'un champ nchar /
nvarchar ?
Si l'on a à gérer plusieurs langues au sein d'une même table, il est à
parier que suivant le contexte on aura besoin une fois d'un tri ou d'une
égalité donc d'une certaine collation, une autre fois d'une autre...
Comment est-ce que l'on peut gérer ça requête à requête ? On peut en
effet imaginer sans peine avoir besoin d'un ordre de tri et comparaison
donné pour une langue A, et des paramètres tout autres pour une langue
B. Si tout est stocké dans la même table... Est-ce que l'on peut définir
un "profil" que l'on pourr aindiquer à chaque requête ? Ou la collation
s'applique forcément à une colonne ? Une table ? Dans ce cas il faudra
soit créer plusieurs colonnes soit plusieurs tables...
Bref, profiter d'Unicode pour pouvoir stocker tous les scripts du monde
c'est bien, mais dans la pratique on peut imaginer rencontrer ce genre
de prb bloquants entre plusieurs langues que l'on doit gérer...
Sylvain Lafontaine wrote:
D'abord une réflexion qui me vient rapidement en lisant vos arguments
: il est quand même très répandu par ici qu'une base ne stocke que
des données en scripts latins. Utiliser Unicode dans ce cas est
plutôt "overkill"
Même si vous ne stocker que des scripts latins et excluant par le fait
tout caractère étranger (grec, russe, etc.), vous pouvez quand même
être frappé par un problème d'encodage dû à un problème de
communication avec une application client et c'est quelque chose que
j'ai vu souvent par le passé.
(...)
Le problème c'est que c'est bien souvent loin d'être le cas. Par
example, il y a deux codepages par machine windows: l'OEM, qui
correspond au codepage DOS classique et le codepage Windows.
Je ne comprend pas cet argument : dans tous les cas, vous devez
contrôler ces 2 points :
- stockage dans la base de données
- charset utilisé par l'application client dans sa connexion à la BDD
+ tout le reste de la chaine jusqu'à la couche présentation...
Tout passer en Unicode ne permet pas de s'affranchir de cela, ou quelque
chose m'échappe ?!!??
Les notions de codage sont la plupart du temps survolées par les
développeurs, qui se disent "j'ai lu qu'il fallait passer en Unicode
pour résoudre le prb" et ne cherchent pas à aller plus loin. Résoudre un
prb sans comprendre sa cause et avec une manip dont on ne saisit pas les
tenants et aboutissants me parait plus que dangereux !
Mais je vous ai peut être mal compris ?
Évidemment, ils y a ceux qui gèrent de très gros systèmes et pour qui
le passage à l'unicode peut représenter une augmentation significative
de coûts parce que leur système travaille déjà à saturation et qu'ils
ne prévoient pas avoir à supporter autre chose que le français dans un
avenir prévisible - ou qu'ils s'en foutent de ne pas supporter autre
chose même si cela pourrait leur être avantageux - et qu'ils ne
prévoient pas interfacer avec autre chose que des applications-clients
ayant strictement le même codepage qu'eux. Pour eux, cela peut être
une décision raisonnable ou un risque calculé que de s'en tenir au
code Ascii. Cependant, s'ils se trompent, les économies réalisées au
début vont fondre plus vite que neige au soleil et ils risquent de
regretter amèrement leur décision par la suite. C'est pourquoi, avant
de prendre cette décision, il faut vraiment savoir où l'on s'en va et
ne pas regarder la question uniquement sous l'aspect économie de
CPU/barrette de mémoire/espace disque. La puissance des machines
double à tous les 18 mois; le coût du programmeur, lui, ne diminue
pas. En fait, dans le cas du programmeur, c'est le contraire qui se
passe: s'il y a une erreur dans le choix de l'Ascii/Unicode, plus vous
aller attendre longtemps avant de corriger l'erreur, plus elle va vous
coûter cher à corriger.
Trois choses après vous avoir lu :
- Des serveurs SQL Server qui sont dimensionné au plus juste, de mon
expérience c'est le cas très largement général... Les machines sont de
plus en plus puissantes, mais les consommations suivent très fidèlement
cette courbe de croissance : en 12 ans d'expérience professionnelle, je
vois toujours autant de prb de performance.
- Si je parlais de scripts latins, c'était pour faire référence à ISO
Latin-9 (iso 8859-15) ou Windows-1252, deux charset 8 bits qui
permettent de stocker toutes les langues d'Europe de l'Ouest. Donc bien
plus que le seul français ! Et on ne peut quand même dire sans se
tromper que la plupart des applications par chez nous (dans les
entreprises françaises) n'ont pas à stocker bien plus... Mais je vous
rejoins évidemment sur le choix à la conception, qui doit être bien
raisonné !
Par ailleurs, parler comme vous le faite "d'ASCII", qui fait en général
référence à us-ascii et donc un charset 7 bits, porte donc assez à
confusion.
- Corriger l'erreur : cela fait partie de mes interrogations... Si l'on
a à modifier le stockage d'une bdd SQL Server vers de l'Unicode,
qu'est-ce que cela va impliquer comme opération ? N'est-ce pas une
"simple" conversion, qui va juste entraîner un arrêt de service le temps
qu'elle prendra ? Les contenus précédents pouvant être recodés en
Unicode, et les anciennes applications clientes se connectant toujours
avec le charset précédent. (pas compris pourquoi vous parliez de "2
versions" ?)
C'est aussi entre autre pourquoi je ne comprend pas la différence entre
ces champs nchar et la collation... on y arrive juste en-dessous.
Pour les questions : je ne comprend pas le lien entre collation et
champs nchar / nvarchar ?
La collation n'est pas associée au stockage des caractères mais à leur
interprétation: tri ou/et égalité de caractères
De ce que j'en avais retenu la collation en bdd regroupait les 3 notions :
- codage au stockage
- comparaison
- tri
Par quel paramètre indique-t-on alors dans quel codage stocker les
champs textes char, varchar ? Est-ce figé à un codage non modifiable, ce
qui expliquerait l'existence de ces nchar et nvarchar ? Donc le choix
entre un codage par défaut ou Unicode ? (que je suppose être UTF-16 ?)
Je viens de revérifier, il y avait bien des noms laissant à penser à des
codage dans les collation sur SQL Server 2000 : sur
http://msdn.microsoft.com/en-us/library/aa226047%28SQL.80%29.aspx par
exemple Latin1_General est marqué comme stocké en "1252" (ce qui laisse
à penser qu'il s'agit de Windows-1252)
(...)
avec comme résultat:
cote
coté
côte
côté
ce qui est incorrect en français standard. D'autres languages
utilisant l'alphabet latins ont des règles de tri et d'équivalence
beaucoup plus complexes que le français, l'allemand ou l'espagnol.
C'était exactement le sens de ma question :
Ensuite, comment gérer les autres critères de la collation (tri,
comparaison) lorsque l'on a dans une même colonne des données dans de
nombreux scripts ? Par exemple, peut-on obtenir un ordre de tri pour
telle famille de scripts, tel autre pour un autre, ... Ou faut-il
alors plutôt envisager un stockage dans une table par collation ?
Dans ce cas, quel est l'intérêt dans la réalité d'un champ nchar /
nvarchar ?
Si l'on a à gérer plusieurs langues au sein d'une même table, il est à
parier que suivant le contexte on aura besoin une fois d'un tri ou d'une
égalité donc d'une certaine collation, une autre fois d'une autre...
Comment est-ce que l'on peut gérer ça requête à requête ? On peut en
effet imaginer sans peine avoir besoin d'un ordre de tri et comparaison
donné pour une langue A, et des paramètres tout autres pour une langue
B. Si tout est stocké dans la même table... Est-ce que l'on peut définir
un "profil" que l'on pourr aindiquer à chaque requête ? Ou la collation
s'applique forcément à une colonne ? Une table ? Dans ce cas il faudra
soit créer plusieurs colonnes soit plusieurs tables...
Bref, profiter d'Unicode pour pouvoir stocker tous les scripts du monde
c'est bien, mais dans la pratique on peut imaginer rencontrer ce genre
de prb bloquants entre plusieurs langues que l'on doit gérer...
Sylvain Lafontaine wrote:D'abord une réflexion qui me vient rapidement en lisant vos arguments
: il est quand même très répandu par ici qu'une base ne stocke que
des données en scripts latins. Utiliser Unicode dans ce cas est
plutôt "overkill"
Même si vous ne stocker que des scripts latins et excluant par le fait
tout caractère étranger (grec, russe, etc.), vous pouvez quand même
être frappé par un problème d'encodage dû à un problème de
communication avec une application client et c'est quelque chose que
j'ai vu souvent par le passé.
(...)Le problème c'est que c'est bien souvent loin d'être le cas. Par
example, il y a deux codepages par machine windows: l'OEM, qui
correspond au codepage DOS classique et le codepage Windows.
Je ne comprend pas cet argument : dans tous les cas, vous devez
contrôler ces 2 points :
- stockage dans la base de données
- charset utilisé par l'application client dans sa connexion à la BDD
+ tout le reste de la chaine jusqu'à la couche présentation...
Tout passer en Unicode ne permet pas de s'affranchir de cela, ou quelque
chose m'échappe ?!!??
Les notions de codage sont la plupart du temps survolées par les
développeurs, qui se disent "j'ai lu qu'il fallait passer en Unicode
pour résoudre le prb" et ne cherchent pas à aller plus loin. Résoudre un
prb sans comprendre sa cause et avec une manip dont on ne saisit pas les
tenants et aboutissants me parait plus que dangereux !
Mais je vous ai peut être mal compris ?Évidemment, ils y a ceux qui gèrent de très gros systèmes et pour qui
le passage à l'unicode peut représenter une augmentation significative
de coûts parce que leur système travaille déjà à saturation et qu'ils
ne prévoient pas avoir à supporter autre chose que le français dans un
avenir prévisible - ou qu'ils s'en foutent de ne pas supporter autre
chose même si cela pourrait leur être avantageux - et qu'ils ne
prévoient pas interfacer avec autre chose que des applications-clients
ayant strictement le même codepage qu'eux. Pour eux, cela peut être
une décision raisonnable ou un risque calculé que de s'en tenir au
code Ascii. Cependant, s'ils se trompent, les économies réalisées au
début vont fondre plus vite que neige au soleil et ils risquent de
regretter amèrement leur décision par la suite. C'est pourquoi, avant
de prendre cette décision, il faut vraiment savoir où l'on s'en va et
ne pas regarder la question uniquement sous l'aspect économie de
CPU/barrette de mémoire/espace disque. La puissance des machines
double à tous les 18 mois; le coût du programmeur, lui, ne diminue
pas. En fait, dans le cas du programmeur, c'est le contraire qui se
passe: s'il y a une erreur dans le choix de l'Ascii/Unicode, plus vous
aller attendre longtemps avant de corriger l'erreur, plus elle va vous
coûter cher à corriger.
Trois choses après vous avoir lu :
- Des serveurs SQL Server qui sont dimensionné au plus juste, de mon
expérience c'est le cas très largement général... Les machines sont de
plus en plus puissantes, mais les consommations suivent très fidèlement
cette courbe de croissance : en 12 ans d'expérience professionnelle, je
vois toujours autant de prb de performance.
- Si je parlais de scripts latins, c'était pour faire référence à ISO
Latin-9 (iso 8859-15) ou Windows-1252, deux charset 8 bits qui
permettent de stocker toutes les langues d'Europe de l'Ouest. Donc bien
plus que le seul français ! Et on ne peut quand même dire sans se
tromper que la plupart des applications par chez nous (dans les
entreprises françaises) n'ont pas à stocker bien plus... Mais je vous
rejoins évidemment sur le choix à la conception, qui doit être bien
raisonné !
Par ailleurs, parler comme vous le faite "d'ASCII", qui fait en général
référence à us-ascii et donc un charset 7 bits, porte donc assez à
confusion.
- Corriger l'erreur : cela fait partie de mes interrogations... Si l'on
a à modifier le stockage d'une bdd SQL Server vers de l'Unicode,
qu'est-ce que cela va impliquer comme opération ? N'est-ce pas une
"simple" conversion, qui va juste entraîner un arrêt de service le temps
qu'elle prendra ? Les contenus précédents pouvant être recodés en
Unicode, et les anciennes applications clientes se connectant toujours
avec le charset précédent. (pas compris pourquoi vous parliez de "2
versions" ?)
C'est aussi entre autre pourquoi je ne comprend pas la différence entre
ces champs nchar et la collation... on y arrive juste en-dessous.Pour les questions : je ne comprend pas le lien entre collation et
champs nchar / nvarchar ?
La collation n'est pas associée au stockage des caractères mais à leur
interprétation: tri ou/et égalité de caractères
De ce que j'en avais retenu la collation en bdd regroupait les 3 notions :
- codage au stockage
- comparaison
- tri
Par quel paramètre indique-t-on alors dans quel codage stocker les
champs textes char, varchar ? Est-ce figé à un codage non modifiable, ce
qui expliquerait l'existence de ces nchar et nvarchar ? Donc le choix
entre un codage par défaut ou Unicode ? (que je suppose être UTF-16 ?)
Je viens de revérifier, il y avait bien des noms laissant à penser à des
codage dans les collation sur SQL Server 2000 : sur
http://msdn.microsoft.com/en-us/library/aa226047%28SQL.80%29.aspx par
exemple Latin1_General est marqué comme stocké en "1252" (ce qui laisse
à penser qu'il s'agit de Windows-1252)
(...)avec comme résultat:
cote
coté
côte
côté
ce qui est incorrect en français standard. D'autres languages
utilisant l'alphabet latins ont des règles de tri et d'équivalence
beaucoup plus complexes que le français, l'allemand ou l'espagnol.
C'était exactement le sens de ma question :Ensuite, comment gérer les autres critères de la collation (tri,
comparaison) lorsque l'on a dans une même colonne des données dans de
nombreux scripts ? Par exemple, peut-on obtenir un ordre de tri pour
telle famille de scripts, tel autre pour un autre, ... Ou faut-il
alors plutôt envisager un stockage dans une table par collation ?
Dans ce cas, quel est l'intérêt dans la réalité d'un champ nchar /
nvarchar ?
Si l'on a à gérer plusieurs langues au sein d'une même table, il est à
parier que suivant le contexte on aura besoin une fois d'un tri ou d'une
égalité donc d'une certaine collation, une autre fois d'une autre...
Comment est-ce que l'on peut gérer ça requête à requête ? On peut en
effet imaginer sans peine avoir besoin d'un ordre de tri et comparaison
donné pour une langue A, et des paramètres tout autres pour une langue
B. Si tout est stocké dans la même table... Est-ce que l'on peut définir
un "profil" que l'on pourr aindiquer à chaque requête ? Ou la collation
s'applique forcément à une colonne ? Une table ? Dans ce cas il faudra
soit créer plusieurs colonnes soit plusieurs tables...
Bref, profiter d'Unicode pour pouvoir stocker tous les scripts du monde
c'est bien, mais dans la pratique on peut imaginer rencontrer ce genre
de prb bloquants entre plusieurs langues que l'on doit gérer...
En 20 ans de bases de données et en près de 15 avec SQL Server, je n'ais
eut qu'une seule fois l'obligation de passer toute la base en UNICODE
parce que le cahier des charges précisait : "une personne peut commander
un service en japonais sur le site et avoir ce service à sa descente
d'avion à New York ce qui suppose que dans les mêmes tables de la base
différentes langues du monde entier seront utilisées."
Dans tous les autres cas :
- ASCII pour les langues latines
- UNICODE pour les langues idéographique
donc au coup par coup à l'installation ce que l'utilisation de DOMAINES
SQL permet facilement par redéfinition des domaines à la création de la
base.
A +
Pierre Goiffon a écrit :Sylvain Lafontaine wrote:D'abord une réflexion qui me vient rapidement en lisant vos arguments :
il est quand même très répandu par ici qu'une base ne stocke que des
données en scripts latins. Utiliser Unicode dans ce cas est plutôt
"overkill"
Même si vous ne stocker que des scripts latins et excluant par le fait
tout caractère étranger (grec, russe, etc.), vous pouvez quand même être
frappé par un problème d'encodage dû à un problème de communication avec
une application client et c'est quelque chose que j'ai vu souvent par le
passé.
(...)Le problème c'est que c'est bien souvent loin d'être le cas. Par
example, il y a deux codepages par machine windows: l'OEM, qui
correspond au codepage DOS classique et le codepage Windows.
Je ne comprend pas cet argument : dans tous les cas, vous devez contrôler
ces 2 points :
- stockage dans la base de données
- charset utilisé par l'application client dans sa connexion à la BDD
+ tout le reste de la chaine jusqu'à la couche présentation...
Tout passer en Unicode ne permet pas de s'affranchir de cela, ou quelque
chose m'échappe ?!!??
Les notions de codage sont la plupart du temps survolées par les
développeurs, qui se disent "j'ai lu qu'il fallait passer en Unicode pour
résoudre le prb" et ne cherchent pas à aller plus loin. Résoudre un prb
sans comprendre sa cause et avec une manip dont on ne saisit pas les
tenants et aboutissants me parait plus que dangereux !
Mais je vous ai peut être mal compris ?Évidemment, ils y a ceux qui gèrent de très gros systèmes et pour qui le
passage à l'unicode peut représenter une augmentation significative de
coûts parce que leur système travaille déjà à saturation et qu'ils ne
prévoient pas avoir à supporter autre chose que le français dans un
avenir prévisible - ou qu'ils s'en foutent de ne pas supporter autre
chose même si cela pourrait leur être avantageux - et qu'ils ne
prévoient pas interfacer avec autre chose que des applications-clients
ayant strictement le même codepage qu'eux. Pour eux, cela peut être une
décision raisonnable ou un risque calculé que de s'en tenir au code
Ascii. Cependant, s'ils se trompent, les économies réalisées au début
vont fondre plus vite que neige au soleil et ils risquent de regretter
amèrement leur décision par la suite. C'est pourquoi, avant de prendre
cette décision, il faut vraiment savoir où l'on s'en va et ne pas
regarder la question uniquement sous l'aspect économie de CPU/barrette
de mémoire/espace disque. La puissance des machines double à tous les
18 mois; le coût du programmeur, lui, ne diminue pas. En fait, dans le
cas du programmeur, c'est le contraire qui se passe: s'il y a une erreur
dans le choix de l'Ascii/Unicode, plus vous aller attendre longtemps
avant de corriger l'erreur, plus elle va vous coûter cher à corriger.
Trois choses après vous avoir lu :
- Des serveurs SQL Server qui sont dimensionné au plus juste, de mon
expérience c'est le cas très largement général... Les machines sont de
plus en plus puissantes, mais les consommations suivent très fidèlement
cette courbe de croissance : en 12 ans d'expérience professionnelle, je
vois toujours autant de prb de performance.
- Si je parlais de scripts latins, c'était pour faire référence à ISO
Latin-9 (iso 8859-15) ou Windows-1252, deux charset 8 bits qui permettent
de stocker toutes les langues d'Europe de l'Ouest. Donc bien plus que le
seul français ! Et on ne peut quand même dire sans se tromper que la
plupart des applications par chez nous (dans les entreprises françaises)
n'ont pas à stocker bien plus... Mais je vous rejoins évidemment sur le
choix à la conception, qui doit être bien raisonné !
Par ailleurs, parler comme vous le faite "d'ASCII", qui fait en général
référence à us-ascii et donc un charset 7 bits, porte donc assez à
confusion.
- Corriger l'erreur : cela fait partie de mes interrogations... Si l'on a
à modifier le stockage d'une bdd SQL Server vers de l'Unicode, qu'est-ce
que cela va impliquer comme opération ? N'est-ce pas une "simple"
conversion, qui va juste entraîner un arrêt de service le temps qu'elle
prendra ? Les contenus précédents pouvant être recodés en Unicode, et les
anciennes applications clientes se connectant toujours avec le charset
précédent. (pas compris pourquoi vous parliez de "2 versions" ?)
C'est aussi entre autre pourquoi je ne comprend pas la différence entre
ces champs nchar et la collation... on y arrive juste en-dessous.Pour les questions : je ne comprend pas le lien entre collation et
champs nchar / nvarchar ?
La collation n'est pas associée au stockage des caractères mais à leur
interprétation: tri ou/et égalité de caractères
De ce que j'en avais retenu la collation en bdd regroupait les 3 notions
:
- codage au stockage
- comparaison
- tri
Par quel paramètre indique-t-on alors dans quel codage stocker les champs
textes char, varchar ? Est-ce figé à un codage non modifiable, ce qui
expliquerait l'existence de ces nchar et nvarchar ? Donc le choix entre
un codage par défaut ou Unicode ? (que je suppose être UTF-16 ?)
Je viens de revérifier, il y avait bien des noms laissant à penser à des
codage dans les collation sur SQL Server 2000 : sur
http://msdn.microsoft.com/en-us/library/aa226047%28SQL.80%29.aspx par
exemple Latin1_General est marqué comme stocké en "1252" (ce qui laisse à
penser qu'il s'agit de Windows-1252)
(...)avec comme résultat:
cote
coté
côte
côté
ce qui est incorrect en français standard. D'autres languages utilisant
l'alphabet latins ont des règles de tri et d'équivalence beaucoup plus
complexes que le français, l'allemand ou l'espagnol.
C'était exactement le sens de ma question :Ensuite, comment gérer les autres critères de la collation (tri,
comparaison) lorsque l'on a dans une même colonne des données dans de
nombreux scripts ? Par exemple, peut-on obtenir un ordre de tri pour
telle famille de scripts, tel autre pour un autre, ... Ou faut-il alors
plutôt envisager un stockage dans une table par collation ? Dans ce
cas, quel est l'intérêt dans la réalité d'un champ nchar / nvarchar ?
Si l'on a à gérer plusieurs langues au sein d'une même table, il est à
parier que suivant le contexte on aura besoin une fois d'un tri ou d'une
égalité donc d'une certaine collation, une autre fois d'une autre...
Comment est-ce que l'on peut gérer ça requête à requête ? On peut en
effet imaginer sans peine avoir besoin d'un ordre de tri et comparaison
donné pour une langue A, et des paramètres tout autres pour une langue B.
Si tout est stocké dans la même table... Est-ce que l'on peut définir un
"profil" que l'on pourr aindiquer à chaque requête ? Ou la collation
s'applique forcément à une colonne ? Une table ? Dans ce cas il faudra
soit créer plusieurs colonnes soit plusieurs tables...
Bref, profiter d'Unicode pour pouvoir stocker tous les scripts du monde
c'est bien, mais dans la pratique on peut imaginer rencontrer ce genre de
prb bloquants entre plusieurs langues que l'on doit gérer...
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
En 20 ans de bases de données et en près de 15 avec SQL Server, je n'ais
eut qu'une seule fois l'obligation de passer toute la base en UNICODE
parce que le cahier des charges précisait : "une personne peut commander
un service en japonais sur le site et avoir ce service à sa descente
d'avion à New York ce qui suppose que dans les mêmes tables de la base
différentes langues du monde entier seront utilisées."
Dans tous les autres cas :
- ASCII pour les langues latines
- UNICODE pour les langues idéographique
donc au coup par coup à l'installation ce que l'utilisation de DOMAINES
SQL permet facilement par redéfinition des domaines à la création de la
base.
A +
Pierre Goiffon a écrit :
Sylvain Lafontaine wrote:
D'abord une réflexion qui me vient rapidement en lisant vos arguments :
il est quand même très répandu par ici qu'une base ne stocke que des
données en scripts latins. Utiliser Unicode dans ce cas est plutôt
"overkill"
Même si vous ne stocker que des scripts latins et excluant par le fait
tout caractère étranger (grec, russe, etc.), vous pouvez quand même être
frappé par un problème d'encodage dû à un problème de communication avec
une application client et c'est quelque chose que j'ai vu souvent par le
passé.
(...)
Le problème c'est que c'est bien souvent loin d'être le cas. Par
example, il y a deux codepages par machine windows: l'OEM, qui
correspond au codepage DOS classique et le codepage Windows.
Je ne comprend pas cet argument : dans tous les cas, vous devez contrôler
ces 2 points :
- stockage dans la base de données
- charset utilisé par l'application client dans sa connexion à la BDD
+ tout le reste de la chaine jusqu'à la couche présentation...
Tout passer en Unicode ne permet pas de s'affranchir de cela, ou quelque
chose m'échappe ?!!??
Les notions de codage sont la plupart du temps survolées par les
développeurs, qui se disent "j'ai lu qu'il fallait passer en Unicode pour
résoudre le prb" et ne cherchent pas à aller plus loin. Résoudre un prb
sans comprendre sa cause et avec une manip dont on ne saisit pas les
tenants et aboutissants me parait plus que dangereux !
Mais je vous ai peut être mal compris ?
Évidemment, ils y a ceux qui gèrent de très gros systèmes et pour qui le
passage à l'unicode peut représenter une augmentation significative de
coûts parce que leur système travaille déjà à saturation et qu'ils ne
prévoient pas avoir à supporter autre chose que le français dans un
avenir prévisible - ou qu'ils s'en foutent de ne pas supporter autre
chose même si cela pourrait leur être avantageux - et qu'ils ne
prévoient pas interfacer avec autre chose que des applications-clients
ayant strictement le même codepage qu'eux. Pour eux, cela peut être une
décision raisonnable ou un risque calculé que de s'en tenir au code
Ascii. Cependant, s'ils se trompent, les économies réalisées au début
vont fondre plus vite que neige au soleil et ils risquent de regretter
amèrement leur décision par la suite. C'est pourquoi, avant de prendre
cette décision, il faut vraiment savoir où l'on s'en va et ne pas
regarder la question uniquement sous l'aspect économie de CPU/barrette
de mémoire/espace disque. La puissance des machines double à tous les
18 mois; le coût du programmeur, lui, ne diminue pas. En fait, dans le
cas du programmeur, c'est le contraire qui se passe: s'il y a une erreur
dans le choix de l'Ascii/Unicode, plus vous aller attendre longtemps
avant de corriger l'erreur, plus elle va vous coûter cher à corriger.
Trois choses après vous avoir lu :
- Des serveurs SQL Server qui sont dimensionné au plus juste, de mon
expérience c'est le cas très largement général... Les machines sont de
plus en plus puissantes, mais les consommations suivent très fidèlement
cette courbe de croissance : en 12 ans d'expérience professionnelle, je
vois toujours autant de prb de performance.
- Si je parlais de scripts latins, c'était pour faire référence à ISO
Latin-9 (iso 8859-15) ou Windows-1252, deux charset 8 bits qui permettent
de stocker toutes les langues d'Europe de l'Ouest. Donc bien plus que le
seul français ! Et on ne peut quand même dire sans se tromper que la
plupart des applications par chez nous (dans les entreprises françaises)
n'ont pas à stocker bien plus... Mais je vous rejoins évidemment sur le
choix à la conception, qui doit être bien raisonné !
Par ailleurs, parler comme vous le faite "d'ASCII", qui fait en général
référence à us-ascii et donc un charset 7 bits, porte donc assez à
confusion.
- Corriger l'erreur : cela fait partie de mes interrogations... Si l'on a
à modifier le stockage d'une bdd SQL Server vers de l'Unicode, qu'est-ce
que cela va impliquer comme opération ? N'est-ce pas une "simple"
conversion, qui va juste entraîner un arrêt de service le temps qu'elle
prendra ? Les contenus précédents pouvant être recodés en Unicode, et les
anciennes applications clientes se connectant toujours avec le charset
précédent. (pas compris pourquoi vous parliez de "2 versions" ?)
C'est aussi entre autre pourquoi je ne comprend pas la différence entre
ces champs nchar et la collation... on y arrive juste en-dessous.
Pour les questions : je ne comprend pas le lien entre collation et
champs nchar / nvarchar ?
La collation n'est pas associée au stockage des caractères mais à leur
interprétation: tri ou/et égalité de caractères
De ce que j'en avais retenu la collation en bdd regroupait les 3 notions
:
- codage au stockage
- comparaison
- tri
Par quel paramètre indique-t-on alors dans quel codage stocker les champs
textes char, varchar ? Est-ce figé à un codage non modifiable, ce qui
expliquerait l'existence de ces nchar et nvarchar ? Donc le choix entre
un codage par défaut ou Unicode ? (que je suppose être UTF-16 ?)
Je viens de revérifier, il y avait bien des noms laissant à penser à des
codage dans les collation sur SQL Server 2000 : sur
http://msdn.microsoft.com/en-us/library/aa226047%28SQL.80%29.aspx par
exemple Latin1_General est marqué comme stocké en "1252" (ce qui laisse à
penser qu'il s'agit de Windows-1252)
(...)
avec comme résultat:
cote
coté
côte
côté
ce qui est incorrect en français standard. D'autres languages utilisant
l'alphabet latins ont des règles de tri et d'équivalence beaucoup plus
complexes que le français, l'allemand ou l'espagnol.
C'était exactement le sens de ma question :
Ensuite, comment gérer les autres critères de la collation (tri,
comparaison) lorsque l'on a dans une même colonne des données dans de
nombreux scripts ? Par exemple, peut-on obtenir un ordre de tri pour
telle famille de scripts, tel autre pour un autre, ... Ou faut-il alors
plutôt envisager un stockage dans une table par collation ? Dans ce
cas, quel est l'intérêt dans la réalité d'un champ nchar / nvarchar ?
Si l'on a à gérer plusieurs langues au sein d'une même table, il est à
parier que suivant le contexte on aura besoin une fois d'un tri ou d'une
égalité donc d'une certaine collation, une autre fois d'une autre...
Comment est-ce que l'on peut gérer ça requête à requête ? On peut en
effet imaginer sans peine avoir besoin d'un ordre de tri et comparaison
donné pour une langue A, et des paramètres tout autres pour une langue B.
Si tout est stocké dans la même table... Est-ce que l'on peut définir un
"profil" que l'on pourr aindiquer à chaque requête ? Ou la collation
s'applique forcément à une colonne ? Une table ? Dans ce cas il faudra
soit créer plusieurs colonnes soit plusieurs tables...
Bref, profiter d'Unicode pour pouvoir stocker tous les scripts du monde
c'est bien, mais dans la pratique on peut imaginer rencontrer ce genre de
prb bloquants entre plusieurs langues que l'on doit gérer...
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
En 20 ans de bases de données et en près de 15 avec SQL Server, je n'ais
eut qu'une seule fois l'obligation de passer toute la base en UNICODE
parce que le cahier des charges précisait : "une personne peut commander
un service en japonais sur le site et avoir ce service à sa descente
d'avion à New York ce qui suppose que dans les mêmes tables de la base
différentes langues du monde entier seront utilisées."
Dans tous les autres cas :
- ASCII pour les langues latines
- UNICODE pour les langues idéographique
donc au coup par coup à l'installation ce que l'utilisation de DOMAINES
SQL permet facilement par redéfinition des domaines à la création de la
base.
A +
Pierre Goiffon a écrit :Sylvain Lafontaine wrote:D'abord une réflexion qui me vient rapidement en lisant vos arguments :
il est quand même très répandu par ici qu'une base ne stocke que des
données en scripts latins. Utiliser Unicode dans ce cas est plutôt
"overkill"
Même si vous ne stocker que des scripts latins et excluant par le fait
tout caractère étranger (grec, russe, etc.), vous pouvez quand même être
frappé par un problème d'encodage dû à un problème de communication avec
une application client et c'est quelque chose que j'ai vu souvent par le
passé.
(...)Le problème c'est que c'est bien souvent loin d'être le cas. Par
example, il y a deux codepages par machine windows: l'OEM, qui
correspond au codepage DOS classique et le codepage Windows.
Je ne comprend pas cet argument : dans tous les cas, vous devez contrôler
ces 2 points :
- stockage dans la base de données
- charset utilisé par l'application client dans sa connexion à la BDD
+ tout le reste de la chaine jusqu'à la couche présentation...
Tout passer en Unicode ne permet pas de s'affranchir de cela, ou quelque
chose m'échappe ?!!??
Les notions de codage sont la plupart du temps survolées par les
développeurs, qui se disent "j'ai lu qu'il fallait passer en Unicode pour
résoudre le prb" et ne cherchent pas à aller plus loin. Résoudre un prb
sans comprendre sa cause et avec une manip dont on ne saisit pas les
tenants et aboutissants me parait plus que dangereux !
Mais je vous ai peut être mal compris ?Évidemment, ils y a ceux qui gèrent de très gros systèmes et pour qui le
passage à l'unicode peut représenter une augmentation significative de
coûts parce que leur système travaille déjà à saturation et qu'ils ne
prévoient pas avoir à supporter autre chose que le français dans un
avenir prévisible - ou qu'ils s'en foutent de ne pas supporter autre
chose même si cela pourrait leur être avantageux - et qu'ils ne
prévoient pas interfacer avec autre chose que des applications-clients
ayant strictement le même codepage qu'eux. Pour eux, cela peut être une
décision raisonnable ou un risque calculé que de s'en tenir au code
Ascii. Cependant, s'ils se trompent, les économies réalisées au début
vont fondre plus vite que neige au soleil et ils risquent de regretter
amèrement leur décision par la suite. C'est pourquoi, avant de prendre
cette décision, il faut vraiment savoir où l'on s'en va et ne pas
regarder la question uniquement sous l'aspect économie de CPU/barrette
de mémoire/espace disque. La puissance des machines double à tous les
18 mois; le coût du programmeur, lui, ne diminue pas. En fait, dans le
cas du programmeur, c'est le contraire qui se passe: s'il y a une erreur
dans le choix de l'Ascii/Unicode, plus vous aller attendre longtemps
avant de corriger l'erreur, plus elle va vous coûter cher à corriger.
Trois choses après vous avoir lu :
- Des serveurs SQL Server qui sont dimensionné au plus juste, de mon
expérience c'est le cas très largement général... Les machines sont de
plus en plus puissantes, mais les consommations suivent très fidèlement
cette courbe de croissance : en 12 ans d'expérience professionnelle, je
vois toujours autant de prb de performance.
- Si je parlais de scripts latins, c'était pour faire référence à ISO
Latin-9 (iso 8859-15) ou Windows-1252, deux charset 8 bits qui permettent
de stocker toutes les langues d'Europe de l'Ouest. Donc bien plus que le
seul français ! Et on ne peut quand même dire sans se tromper que la
plupart des applications par chez nous (dans les entreprises françaises)
n'ont pas à stocker bien plus... Mais je vous rejoins évidemment sur le
choix à la conception, qui doit être bien raisonné !
Par ailleurs, parler comme vous le faite "d'ASCII", qui fait en général
référence à us-ascii et donc un charset 7 bits, porte donc assez à
confusion.
- Corriger l'erreur : cela fait partie de mes interrogations... Si l'on a
à modifier le stockage d'une bdd SQL Server vers de l'Unicode, qu'est-ce
que cela va impliquer comme opération ? N'est-ce pas une "simple"
conversion, qui va juste entraîner un arrêt de service le temps qu'elle
prendra ? Les contenus précédents pouvant être recodés en Unicode, et les
anciennes applications clientes se connectant toujours avec le charset
précédent. (pas compris pourquoi vous parliez de "2 versions" ?)
C'est aussi entre autre pourquoi je ne comprend pas la différence entre
ces champs nchar et la collation... on y arrive juste en-dessous.Pour les questions : je ne comprend pas le lien entre collation et
champs nchar / nvarchar ?
La collation n'est pas associée au stockage des caractères mais à leur
interprétation: tri ou/et égalité de caractères
De ce que j'en avais retenu la collation en bdd regroupait les 3 notions
:
- codage au stockage
- comparaison
- tri
Par quel paramètre indique-t-on alors dans quel codage stocker les champs
textes char, varchar ? Est-ce figé à un codage non modifiable, ce qui
expliquerait l'existence de ces nchar et nvarchar ? Donc le choix entre
un codage par défaut ou Unicode ? (que je suppose être UTF-16 ?)
Je viens de revérifier, il y avait bien des noms laissant à penser à des
codage dans les collation sur SQL Server 2000 : sur
http://msdn.microsoft.com/en-us/library/aa226047%28SQL.80%29.aspx par
exemple Latin1_General est marqué comme stocké en "1252" (ce qui laisse à
penser qu'il s'agit de Windows-1252)
(...)avec comme résultat:
cote
coté
côte
côté
ce qui est incorrect en français standard. D'autres languages utilisant
l'alphabet latins ont des règles de tri et d'équivalence beaucoup plus
complexes que le français, l'allemand ou l'espagnol.
C'était exactement le sens de ma question :Ensuite, comment gérer les autres critères de la collation (tri,
comparaison) lorsque l'on a dans une même colonne des données dans de
nombreux scripts ? Par exemple, peut-on obtenir un ordre de tri pour
telle famille de scripts, tel autre pour un autre, ... Ou faut-il alors
plutôt envisager un stockage dans une table par collation ? Dans ce
cas, quel est l'intérêt dans la réalité d'un champ nchar / nvarchar ?
Si l'on a à gérer plusieurs langues au sein d'une même table, il est à
parier que suivant le contexte on aura besoin une fois d'un tri ou d'une
égalité donc d'une certaine collation, une autre fois d'une autre...
Comment est-ce que l'on peut gérer ça requête à requête ? On peut en
effet imaginer sans peine avoir besoin d'un ordre de tri et comparaison
donné pour une langue A, et des paramètres tout autres pour une langue B.
Si tout est stocké dans la même table... Est-ce que l'on peut définir un
"profil" que l'on pourr aindiquer à chaque requête ? Ou la collation
s'applique forcément à une colonne ? Une table ? Dans ce cas il faudra
soit créer plusieurs colonnes soit plusieurs tables...
Bref, profiter d'Unicode pour pouvoir stocker tous les scripts du monde
c'est bien, mais dans la pratique on peut imaginer rencontrer ce genre de
prb bloquants entre plusieurs langues que l'on doit gérer...
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
Voici ce que Microsoft dit sur le sujet
http://msdn.microsoft.com/en-us/library/ee240835%28SQL.105%29.aspx
Il est cependant certain que l'espace peut-etre est un probleme dans
certains cas.
Sinon comment expliquer que SQL Server 2008 R2 apporte comme nouveauté
la compression Unicode
http://msdn.microsoft.com/en-us/library/ms189617.aspx
Voici ce que Microsoft dit sur le sujet
http://msdn.microsoft.com/en-us/library/ee240835%28SQL.105%29.aspx
Il est cependant certain que l'espace peut-etre est un probleme dans
certains cas.
Sinon comment expliquer que SQL Server 2008 R2 apporte comme nouveauté
la compression Unicode
http://msdn.microsoft.com/en-us/library/ms189617.aspx
Voici ce que Microsoft dit sur le sujet
http://msdn.microsoft.com/en-us/library/ee240835%28SQL.105%29.aspx
Il est cependant certain que l'espace peut-etre est un probleme dans
certains cas.
Sinon comment expliquer que SQL Server 2008 R2 apporte comme nouveauté
la compression Unicode
http://msdn.microsoft.com/en-us/library/ms189617.aspx
Voici ce que Microsoft dit sur le sujet
http://msdn.microsoft.com/en-us/library/ee240835%28SQL.105%29.aspx
Il est cependant certain que l'espace peut-etre est un probleme dans
certains cas.
Sinon comment expliquer que SQL Server 2008 R2 apporte comme nouveauté la
compression Unicode
http://msdn.microsoft.com/en-us/library/ms189617.aspx
Il est vrai que ces dernieres années, la tension s'est largement relachée
sur les performances avec la puissance materielle des serveurs
J'ai vu beaucoup prendre la decision de passer tout en Unicode.
Pourquoi pas?
Mais moi, je continue, comme avant, á utiliser le deux
Unicode ou pas Unicode, c'est fondamentalement le business qui decide en
premier
Je me vois mal codifier une colonne Sex avec NCHAR(1) ( Exemple reel chez
un client)
Mais bon,
Bien cordialement
Med Bouchenafa
"Fred BROUARD" wrote in message
news:#En 20 ans de bases de données et en près de 15 avec SQL Server, je n'ais
eut qu'une seule fois l'obligation de passer toute la base en UNICODE
parce que le cahier des charges précisait : "une personne peut commander
un service en japonais sur le site et avoir ce service à sa descente
d'avion à New York ce qui suppose que dans les mêmes tables de la base
différentes langues du monde entier seront utilisées."
Dans tous les autres cas :
- ASCII pour les langues latines
- UNICODE pour les langues idéographique
donc au coup par coup à l'installation ce que l'utilisation de DOMAINES
SQL permet facilement par redéfinition des domaines à la création de la
base.
A +
Pierre Goiffon a écrit :Sylvain Lafontaine wrote:D'abord une réflexion qui me vient rapidement en lisant vos arguments
: il est quand même très répandu par ici qu'une base ne stocke que des
données en scripts latins. Utiliser Unicode dans ce cas est plutôt
"overkill"
Même si vous ne stocker que des scripts latins et excluant par le fait
tout caractère étranger (grec, russe, etc.), vous pouvez quand même
être frappé par un problème d'encodage dû à un problème de
communication avec une application client et c'est quelque chose que
j'ai vu souvent par le passé.
(...)Le problème c'est que c'est bien souvent loin d'être le cas. Par
example, il y a deux codepages par machine windows: l'OEM, qui
correspond au codepage DOS classique et le codepage Windows.
Je ne comprend pas cet argument : dans tous les cas, vous devez
contrôler ces 2 points :
- stockage dans la base de données
- charset utilisé par l'application client dans sa connexion à la BDD
+ tout le reste de la chaine jusqu'à la couche présentation...
Tout passer en Unicode ne permet pas de s'affranchir de cela, ou quelque
chose m'échappe ?!!??
Les notions de codage sont la plupart du temps survolées par les
développeurs, qui se disent "j'ai lu qu'il fallait passer en Unicode
pour résoudre le prb" et ne cherchent pas à aller plus loin. Résoudre un
prb sans comprendre sa cause et avec une manip dont on ne saisit pas les
tenants et aboutissants me parait plus que dangereux !
Mais je vous ai peut être mal compris ?Évidemment, ils y a ceux qui gèrent de très gros systèmes et pour qui
le passage à l'unicode peut représenter une augmentation significative
de coûts parce que leur système travaille déjà à saturation et qu'ils
ne prévoient pas avoir à supporter autre chose que le français dans un
avenir prévisible - ou qu'ils s'en foutent de ne pas supporter autre
chose même si cela pourrait leur être avantageux - et qu'ils ne
prévoient pas interfacer avec autre chose que des applications-clients
ayant strictement le même codepage qu'eux. Pour eux, cela peut être
une décision raisonnable ou un risque calculé que de s'en tenir au code
Ascii. Cependant, s'ils se trompent, les économies réalisées au début
vont fondre plus vite que neige au soleil et ils risquent de regretter
amèrement leur décision par la suite. C'est pourquoi, avant de prendre
cette décision, il faut vraiment savoir où l'on s'en va et ne pas
regarder la question uniquement sous l'aspect économie de CPU/barrette
de mémoire/espace disque. La puissance des machines double à tous les
18 mois; le coût du programmeur, lui, ne diminue pas. En fait, dans le
cas du programmeur, c'est le contraire qui se passe: s'il y a une
erreur dans le choix de l'Ascii/Unicode, plus vous aller attendre
longtemps avant de corriger l'erreur, plus elle va vous coûter cher à
corriger.
Trois choses après vous avoir lu :
- Des serveurs SQL Server qui sont dimensionné au plus juste, de mon
expérience c'est le cas très largement général... Les machines sont de
plus en plus puissantes, mais les consommations suivent très fidèlement
cette courbe de croissance : en 12 ans d'expérience professionnelle, je
vois toujours autant de prb de performance.
- Si je parlais de scripts latins, c'était pour faire référence à ISO
Latin-9 (iso 8859-15) ou Windows-1252, deux charset 8 bits qui
permettent de stocker toutes les langues d'Europe de l'Ouest. Donc bien
plus que le seul français ! Et on ne peut quand même dire sans se
tromper que la plupart des applications par chez nous (dans les
entreprises françaises) n'ont pas à stocker bien plus... Mais je vous
rejoins évidemment sur le choix à la conception, qui doit être bien
raisonné !
Par ailleurs, parler comme vous le faite "d'ASCII", qui fait en général
référence à us-ascii et donc un charset 7 bits, porte donc assez à
confusion.
- Corriger l'erreur : cela fait partie de mes interrogations... Si l'on
a à modifier le stockage d'une bdd SQL Server vers de l'Unicode,
qu'est-ce que cela va impliquer comme opération ? N'est-ce pas une
"simple" conversion, qui va juste entraîner un arrêt de service le temps
qu'elle prendra ? Les contenus précédents pouvant être recodés en
Unicode, et les anciennes applications clientes se connectant toujours
avec le charset précédent. (pas compris pourquoi vous parliez de "2
versions" ?)
C'est aussi entre autre pourquoi je ne comprend pas la différence entre
ces champs nchar et la collation... on y arrive juste en-dessous.Pour les questions : je ne comprend pas le lien entre collation et
champs nchar / nvarchar ?
La collation n'est pas associée au stockage des caractères mais à leur
interprétation: tri ou/et égalité de caractères
De ce que j'en avais retenu la collation en bdd regroupait les 3 notions
:
- codage au stockage
- comparaison
- tri
Par quel paramètre indique-t-on alors dans quel codage stocker les
champs textes char, varchar ? Est-ce figé à un codage non modifiable, ce
qui expliquerait l'existence de ces nchar et nvarchar ? Donc le choix
entre un codage par défaut ou Unicode ? (que je suppose être UTF-16 ?)
Je viens de revérifier, il y avait bien des noms laissant à penser à des
codage dans les collation sur SQL Server 2000 : sur
http://msdn.microsoft.com/en-us/library/aa226047%28SQL.80%29.aspx par
exemple Latin1_General est marqué comme stocké en "1252" (ce qui laisse
à penser qu'il s'agit de Windows-1252)
(...)avec comme résultat:
cote
coté
côte
côté
ce qui est incorrect en français standard. D'autres languages
utilisant l'alphabet latins ont des règles de tri et d'équivalence
beaucoup plus complexes que le français, l'allemand ou l'espagnol.
C'était exactement le sens de ma question :Ensuite, comment gérer les autres critères de la collation (tri,
comparaison) lorsque l'on a dans une même colonne des données dans de
nombreux scripts ? Par exemple, peut-on obtenir un ordre de tri pour
telle famille de scripts, tel autre pour un autre, ... Ou faut-il
alors plutôt envisager un stockage dans une table par collation ? Dans
ce cas, quel est l'intérêt dans la réalité d'un champ nchar / nvarchar
?
Si l'on a à gérer plusieurs langues au sein d'une même table, il est à
parier que suivant le contexte on aura besoin une fois d'un tri ou d'une
égalité donc d'une certaine collation, une autre fois d'une autre...
Comment est-ce que l'on peut gérer ça requête à requête ? On peut en
effet imaginer sans peine avoir besoin d'un ordre de tri et comparaison
donné pour une langue A, et des paramètres tout autres pour une langue
B. Si tout est stocké dans la même table... Est-ce que l'on peut définir
un "profil" que l'on pourr aindiquer à chaque requête ? Ou la collation
s'applique forcément à une colonne ? Une table ? Dans ce cas il faudra
soit créer plusieurs colonnes soit plusieurs tables...
Bref, profiter d'Unicode pour pouvoir stocker tous les scripts du monde
c'est bien, mais dans la pratique on peut imaginer rencontrer ce genre
de prb bloquants entre plusieurs langues que l'on doit gérer...
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
Voici ce que Microsoft dit sur le sujet
http://msdn.microsoft.com/en-us/library/ee240835%28SQL.105%29.aspx
Il est cependant certain que l'espace peut-etre est un probleme dans
certains cas.
Sinon comment expliquer que SQL Server 2008 R2 apporte comme nouveauté la
compression Unicode
http://msdn.microsoft.com/en-us/library/ms189617.aspx
Il est vrai que ces dernieres années, la tension s'est largement relachée
sur les performances avec la puissance materielle des serveurs
J'ai vu beaucoup prendre la decision de passer tout en Unicode.
Pourquoi pas?
Mais moi, je continue, comme avant, á utiliser le deux
Unicode ou pas Unicode, c'est fondamentalement le business qui decide en
premier
Je me vois mal codifier une colonne Sex avec NCHAR(1) ( Exemple reel chez
un client)
Mais bon,
Bien cordialement
Med Bouchenafa
"Fred BROUARD" <brouardf@club-internet.fr> wrote in message
news:#8yoeG4QKHA.4020@TK2MSFTNGP05.phx.gbl...
En 20 ans de bases de données et en près de 15 avec SQL Server, je n'ais
eut qu'une seule fois l'obligation de passer toute la base en UNICODE
parce que le cahier des charges précisait : "une personne peut commander
un service en japonais sur le site et avoir ce service à sa descente
d'avion à New York ce qui suppose que dans les mêmes tables de la base
différentes langues du monde entier seront utilisées."
Dans tous les autres cas :
- ASCII pour les langues latines
- UNICODE pour les langues idéographique
donc au coup par coup à l'installation ce que l'utilisation de DOMAINES
SQL permet facilement par redéfinition des domaines à la création de la
base.
A +
Pierre Goiffon a écrit :
Sylvain Lafontaine wrote:
D'abord une réflexion qui me vient rapidement en lisant vos arguments
: il est quand même très répandu par ici qu'une base ne stocke que des
données en scripts latins. Utiliser Unicode dans ce cas est plutôt
"overkill"
Même si vous ne stocker que des scripts latins et excluant par le fait
tout caractère étranger (grec, russe, etc.), vous pouvez quand même
être frappé par un problème d'encodage dû à un problème de
communication avec une application client et c'est quelque chose que
j'ai vu souvent par le passé.
(...)
Le problème c'est que c'est bien souvent loin d'être le cas. Par
example, il y a deux codepages par machine windows: l'OEM, qui
correspond au codepage DOS classique et le codepage Windows.
Je ne comprend pas cet argument : dans tous les cas, vous devez
contrôler ces 2 points :
- stockage dans la base de données
- charset utilisé par l'application client dans sa connexion à la BDD
+ tout le reste de la chaine jusqu'à la couche présentation...
Tout passer en Unicode ne permet pas de s'affranchir de cela, ou quelque
chose m'échappe ?!!??
Les notions de codage sont la plupart du temps survolées par les
développeurs, qui se disent "j'ai lu qu'il fallait passer en Unicode
pour résoudre le prb" et ne cherchent pas à aller plus loin. Résoudre un
prb sans comprendre sa cause et avec une manip dont on ne saisit pas les
tenants et aboutissants me parait plus que dangereux !
Mais je vous ai peut être mal compris ?
Évidemment, ils y a ceux qui gèrent de très gros systèmes et pour qui
le passage à l'unicode peut représenter une augmentation significative
de coûts parce que leur système travaille déjà à saturation et qu'ils
ne prévoient pas avoir à supporter autre chose que le français dans un
avenir prévisible - ou qu'ils s'en foutent de ne pas supporter autre
chose même si cela pourrait leur être avantageux - et qu'ils ne
prévoient pas interfacer avec autre chose que des applications-clients
ayant strictement le même codepage qu'eux. Pour eux, cela peut être
une décision raisonnable ou un risque calculé que de s'en tenir au code
Ascii. Cependant, s'ils se trompent, les économies réalisées au début
vont fondre plus vite que neige au soleil et ils risquent de regretter
amèrement leur décision par la suite. C'est pourquoi, avant de prendre
cette décision, il faut vraiment savoir où l'on s'en va et ne pas
regarder la question uniquement sous l'aspect économie de CPU/barrette
de mémoire/espace disque. La puissance des machines double à tous les
18 mois; le coût du programmeur, lui, ne diminue pas. En fait, dans le
cas du programmeur, c'est le contraire qui se passe: s'il y a une
erreur dans le choix de l'Ascii/Unicode, plus vous aller attendre
longtemps avant de corriger l'erreur, plus elle va vous coûter cher à
corriger.
Trois choses après vous avoir lu :
- Des serveurs SQL Server qui sont dimensionné au plus juste, de mon
expérience c'est le cas très largement général... Les machines sont de
plus en plus puissantes, mais les consommations suivent très fidèlement
cette courbe de croissance : en 12 ans d'expérience professionnelle, je
vois toujours autant de prb de performance.
- Si je parlais de scripts latins, c'était pour faire référence à ISO
Latin-9 (iso 8859-15) ou Windows-1252, deux charset 8 bits qui
permettent de stocker toutes les langues d'Europe de l'Ouest. Donc bien
plus que le seul français ! Et on ne peut quand même dire sans se
tromper que la plupart des applications par chez nous (dans les
entreprises françaises) n'ont pas à stocker bien plus... Mais je vous
rejoins évidemment sur le choix à la conception, qui doit être bien
raisonné !
Par ailleurs, parler comme vous le faite "d'ASCII", qui fait en général
référence à us-ascii et donc un charset 7 bits, porte donc assez à
confusion.
- Corriger l'erreur : cela fait partie de mes interrogations... Si l'on
a à modifier le stockage d'une bdd SQL Server vers de l'Unicode,
qu'est-ce que cela va impliquer comme opération ? N'est-ce pas une
"simple" conversion, qui va juste entraîner un arrêt de service le temps
qu'elle prendra ? Les contenus précédents pouvant être recodés en
Unicode, et les anciennes applications clientes se connectant toujours
avec le charset précédent. (pas compris pourquoi vous parliez de "2
versions" ?)
C'est aussi entre autre pourquoi je ne comprend pas la différence entre
ces champs nchar et la collation... on y arrive juste en-dessous.
Pour les questions : je ne comprend pas le lien entre collation et
champs nchar / nvarchar ?
La collation n'est pas associée au stockage des caractères mais à leur
interprétation: tri ou/et égalité de caractères
De ce que j'en avais retenu la collation en bdd regroupait les 3 notions
:
- codage au stockage
- comparaison
- tri
Par quel paramètre indique-t-on alors dans quel codage stocker les
champs textes char, varchar ? Est-ce figé à un codage non modifiable, ce
qui expliquerait l'existence de ces nchar et nvarchar ? Donc le choix
entre un codage par défaut ou Unicode ? (que je suppose être UTF-16 ?)
Je viens de revérifier, il y avait bien des noms laissant à penser à des
codage dans les collation sur SQL Server 2000 : sur
http://msdn.microsoft.com/en-us/library/aa226047%28SQL.80%29.aspx par
exemple Latin1_General est marqué comme stocké en "1252" (ce qui laisse
à penser qu'il s'agit de Windows-1252)
(...)
avec comme résultat:
cote
coté
côte
côté
ce qui est incorrect en français standard. D'autres languages
utilisant l'alphabet latins ont des règles de tri et d'équivalence
beaucoup plus complexes que le français, l'allemand ou l'espagnol.
C'était exactement le sens de ma question :
Ensuite, comment gérer les autres critères de la collation (tri,
comparaison) lorsque l'on a dans une même colonne des données dans de
nombreux scripts ? Par exemple, peut-on obtenir un ordre de tri pour
telle famille de scripts, tel autre pour un autre, ... Ou faut-il
alors plutôt envisager un stockage dans une table par collation ? Dans
ce cas, quel est l'intérêt dans la réalité d'un champ nchar / nvarchar
?
Si l'on a à gérer plusieurs langues au sein d'une même table, il est à
parier que suivant le contexte on aura besoin une fois d'un tri ou d'une
égalité donc d'une certaine collation, une autre fois d'une autre...
Comment est-ce que l'on peut gérer ça requête à requête ? On peut en
effet imaginer sans peine avoir besoin d'un ordre de tri et comparaison
donné pour une langue A, et des paramètres tout autres pour une langue
B. Si tout est stocké dans la même table... Est-ce que l'on peut définir
un "profil" que l'on pourr aindiquer à chaque requête ? Ou la collation
s'applique forcément à une colonne ? Une table ? Dans ce cas il faudra
soit créer plusieurs colonnes soit plusieurs tables...
Bref, profiter d'Unicode pour pouvoir stocker tous les scripts du monde
c'est bien, mais dans la pratique on peut imaginer rencontrer ce genre
de prb bloquants entre plusieurs langues que l'on doit gérer...
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
Voici ce que Microsoft dit sur le sujet
http://msdn.microsoft.com/en-us/library/ee240835%28SQL.105%29.aspx
Il est cependant certain que l'espace peut-etre est un probleme dans
certains cas.
Sinon comment expliquer que SQL Server 2008 R2 apporte comme nouveauté la
compression Unicode
http://msdn.microsoft.com/en-us/library/ms189617.aspx
Il est vrai que ces dernieres années, la tension s'est largement relachée
sur les performances avec la puissance materielle des serveurs
J'ai vu beaucoup prendre la decision de passer tout en Unicode.
Pourquoi pas?
Mais moi, je continue, comme avant, á utiliser le deux
Unicode ou pas Unicode, c'est fondamentalement le business qui decide en
premier
Je me vois mal codifier une colonne Sex avec NCHAR(1) ( Exemple reel chez
un client)
Mais bon,
Bien cordialement
Med Bouchenafa
"Fred BROUARD" wrote in message
news:#En 20 ans de bases de données et en près de 15 avec SQL Server, je n'ais
eut qu'une seule fois l'obligation de passer toute la base en UNICODE
parce que le cahier des charges précisait : "une personne peut commander
un service en japonais sur le site et avoir ce service à sa descente
d'avion à New York ce qui suppose que dans les mêmes tables de la base
différentes langues du monde entier seront utilisées."
Dans tous les autres cas :
- ASCII pour les langues latines
- UNICODE pour les langues idéographique
donc au coup par coup à l'installation ce que l'utilisation de DOMAINES
SQL permet facilement par redéfinition des domaines à la création de la
base.
A +
Pierre Goiffon a écrit :Sylvain Lafontaine wrote:D'abord une réflexion qui me vient rapidement en lisant vos arguments
: il est quand même très répandu par ici qu'une base ne stocke que des
données en scripts latins. Utiliser Unicode dans ce cas est plutôt
"overkill"
Même si vous ne stocker que des scripts latins et excluant par le fait
tout caractère étranger (grec, russe, etc.), vous pouvez quand même
être frappé par un problème d'encodage dû à un problème de
communication avec une application client et c'est quelque chose que
j'ai vu souvent par le passé.
(...)Le problème c'est que c'est bien souvent loin d'être le cas. Par
example, il y a deux codepages par machine windows: l'OEM, qui
correspond au codepage DOS classique et le codepage Windows.
Je ne comprend pas cet argument : dans tous les cas, vous devez
contrôler ces 2 points :
- stockage dans la base de données
- charset utilisé par l'application client dans sa connexion à la BDD
+ tout le reste de la chaine jusqu'à la couche présentation...
Tout passer en Unicode ne permet pas de s'affranchir de cela, ou quelque
chose m'échappe ?!!??
Les notions de codage sont la plupart du temps survolées par les
développeurs, qui se disent "j'ai lu qu'il fallait passer en Unicode
pour résoudre le prb" et ne cherchent pas à aller plus loin. Résoudre un
prb sans comprendre sa cause et avec une manip dont on ne saisit pas les
tenants et aboutissants me parait plus que dangereux !
Mais je vous ai peut être mal compris ?Évidemment, ils y a ceux qui gèrent de très gros systèmes et pour qui
le passage à l'unicode peut représenter une augmentation significative
de coûts parce que leur système travaille déjà à saturation et qu'ils
ne prévoient pas avoir à supporter autre chose que le français dans un
avenir prévisible - ou qu'ils s'en foutent de ne pas supporter autre
chose même si cela pourrait leur être avantageux - et qu'ils ne
prévoient pas interfacer avec autre chose que des applications-clients
ayant strictement le même codepage qu'eux. Pour eux, cela peut être
une décision raisonnable ou un risque calculé que de s'en tenir au code
Ascii. Cependant, s'ils se trompent, les économies réalisées au début
vont fondre plus vite que neige au soleil et ils risquent de regretter
amèrement leur décision par la suite. C'est pourquoi, avant de prendre
cette décision, il faut vraiment savoir où l'on s'en va et ne pas
regarder la question uniquement sous l'aspect économie de CPU/barrette
de mémoire/espace disque. La puissance des machines double à tous les
18 mois; le coût du programmeur, lui, ne diminue pas. En fait, dans le
cas du programmeur, c'est le contraire qui se passe: s'il y a une
erreur dans le choix de l'Ascii/Unicode, plus vous aller attendre
longtemps avant de corriger l'erreur, plus elle va vous coûter cher à
corriger.
Trois choses après vous avoir lu :
- Des serveurs SQL Server qui sont dimensionné au plus juste, de mon
expérience c'est le cas très largement général... Les machines sont de
plus en plus puissantes, mais les consommations suivent très fidèlement
cette courbe de croissance : en 12 ans d'expérience professionnelle, je
vois toujours autant de prb de performance.
- Si je parlais de scripts latins, c'était pour faire référence à ISO
Latin-9 (iso 8859-15) ou Windows-1252, deux charset 8 bits qui
permettent de stocker toutes les langues d'Europe de l'Ouest. Donc bien
plus que le seul français ! Et on ne peut quand même dire sans se
tromper que la plupart des applications par chez nous (dans les
entreprises françaises) n'ont pas à stocker bien plus... Mais je vous
rejoins évidemment sur le choix à la conception, qui doit être bien
raisonné !
Par ailleurs, parler comme vous le faite "d'ASCII", qui fait en général
référence à us-ascii et donc un charset 7 bits, porte donc assez à
confusion.
- Corriger l'erreur : cela fait partie de mes interrogations... Si l'on
a à modifier le stockage d'une bdd SQL Server vers de l'Unicode,
qu'est-ce que cela va impliquer comme opération ? N'est-ce pas une
"simple" conversion, qui va juste entraîner un arrêt de service le temps
qu'elle prendra ? Les contenus précédents pouvant être recodés en
Unicode, et les anciennes applications clientes se connectant toujours
avec le charset précédent. (pas compris pourquoi vous parliez de "2
versions" ?)
C'est aussi entre autre pourquoi je ne comprend pas la différence entre
ces champs nchar et la collation... on y arrive juste en-dessous.Pour les questions : je ne comprend pas le lien entre collation et
champs nchar / nvarchar ?
La collation n'est pas associée au stockage des caractères mais à leur
interprétation: tri ou/et égalité de caractères
De ce que j'en avais retenu la collation en bdd regroupait les 3 notions
:
- codage au stockage
- comparaison
- tri
Par quel paramètre indique-t-on alors dans quel codage stocker les
champs textes char, varchar ? Est-ce figé à un codage non modifiable, ce
qui expliquerait l'existence de ces nchar et nvarchar ? Donc le choix
entre un codage par défaut ou Unicode ? (que je suppose être UTF-16 ?)
Je viens de revérifier, il y avait bien des noms laissant à penser à des
codage dans les collation sur SQL Server 2000 : sur
http://msdn.microsoft.com/en-us/library/aa226047%28SQL.80%29.aspx par
exemple Latin1_General est marqué comme stocké en "1252" (ce qui laisse
à penser qu'il s'agit de Windows-1252)
(...)avec comme résultat:
cote
coté
côte
côté
ce qui est incorrect en français standard. D'autres languages
utilisant l'alphabet latins ont des règles de tri et d'équivalence
beaucoup plus complexes que le français, l'allemand ou l'espagnol.
C'était exactement le sens de ma question :Ensuite, comment gérer les autres critères de la collation (tri,
comparaison) lorsque l'on a dans une même colonne des données dans de
nombreux scripts ? Par exemple, peut-on obtenir un ordre de tri pour
telle famille de scripts, tel autre pour un autre, ... Ou faut-il
alors plutôt envisager un stockage dans une table par collation ? Dans
ce cas, quel est l'intérêt dans la réalité d'un champ nchar / nvarchar
?
Si l'on a à gérer plusieurs langues au sein d'une même table, il est à
parier que suivant le contexte on aura besoin une fois d'un tri ou d'une
égalité donc d'une certaine collation, une autre fois d'une autre...
Comment est-ce que l'on peut gérer ça requête à requête ? On peut en
effet imaginer sans peine avoir besoin d'un ordre de tri et comparaison
donné pour une langue A, et des paramètres tout autres pour une langue
B. Si tout est stocké dans la même table... Est-ce que l'on peut définir
un "profil" que l'on pourr aindiquer à chaque requête ? Ou la collation
s'applique forcément à une colonne ? Une table ? Dans ce cas il faudra
soit créer plusieurs colonnes soit plusieurs tables...
Bref, profiter d'Unicode pour pouvoir stocker tous les scripts du monde
c'est bien, mais dans la pratique on peut imaginer rencontrer ce genre
de prb bloquants entre plusieurs langues que l'on doit gérer...
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************