Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

nchar

30 réponses
Avatar
Fred
Bonjour,
Je dois rajouter toute une série de tables dans une DB existante et dans
cette DB, les data types utilisés sont le plus souvent nvarchar (32) ou 64 ou
100. Pour les tables que je dois rajouter, c'est donc préférable que
j'utilise les mêmes ? Quel est l'avantage de ces datatypes par rapport au
varchar normal ? Performance ? On parle de Unicode sur msdn mais ça ne me
parle pas bcp ...
Pouvez-vous m'éclairer ?
Merci d'avance !

10 réponses

1 2 3
Avatar
Sylvain Lafontaine
C'est pour vous éviter toute une série de problèmes avec l'utilisation des
accents français (entre autre) et du symbol euro si votre base de données
est accédé par des machines utilisant un code page windows différent (genre
grec ou russe ou autre).

À moins que vous n'ayez un problème spécifique, arrêtez de vous poser des
questions et utilisez nvarchar() partout à la place de varchar().

--
Sylvain Lafontaine, ing.
MVP pour « Windows Live Platform »
Courriel: sylvain2009 sylvainlafontaine com (remplissez les blancs, svp.)
Consultant indépendant et programmation à distance pour Access et
SQL-Server.


"Fred" wrote in message
news:
Bonjour,
Je dois rajouter toute une série de tables dans une DB existante et dans
cette DB, les data types utilisés sont le plus souvent nvarchar (32) ou 64
ou
100. Pour les tables que je dois rajouter, c'est donc préférable que
j'utilise les mêmes ? Quel est l'avantage de ces datatypes par rapport au
varchar normal ? Performance ? On parle de Unicode sur msdn mais ça ne me
parle pas bcp ...
Pouvez-vous m'éclairer ?
Merci d'avance !


Avatar
Fred
Voilà une réponse super claire. Merci beaucoup ...

"Sylvain Lafontaine" a écrit :

C'est pour vous éviter toute une série de problèmes avec l'utilisation des
accents français (entre autre) et du symbol euro si votre base de données
est accédé par des machines utilisant un code page windows différent (genre
grec ou russe ou autre).

À moins que vous n'ayez un problème spécifique, arrêtez de vous poser des
questions et utilisez nvarchar() partout à la place de varchar().

--
Sylvain Lafontaine, ing.
MVP pour « Windows Live Platform »
Courriel: sylvain2009 sylvainlafontaine com (remplissez les blancs, svp.)
Consultant indépendant et programmation à distance pour Access et
SQL-Server.


"Fred" wrote in message
news:
> Bonjour,
> Je dois rajouter toute une série de tables dans une DB existante et dans
> cette DB, les data types utilisés sont le plus souvent nvarchar (32) ou 64
> ou
> 100. Pour les tables que je dois rajouter, c'est donc préférable que
> j'utilise les mêmes ? Quel est l'avantage de ces datatypes par rapport au
> varchar normal ? Performance ? On parle de Unicode sur msdn mais ça ne me
> parle pas bcp ...
> Pouvez-vous m'éclairer ?
> Merci d'avance !





Avatar
Sylvain Lafontaine
N'oubliez pas d'utiliser le préfixe N' devant vos constantes chaîne de
caractère, genre:

Select * from MyTable where Nom = N'François'

Obligatoire seulement s'ils contiennent des codes (lettres) non-ASCII mais
vous ne perdez rien à prendre la bonne habitude de le mettre partout.

--
Sylvain Lafontaine, ing.
MVP pour « Windows Live Platform »
Courriel: sylvain2009 sylvainlafontaine com (remplissez les blancs, svp.)
Consultant indépendant et programmation à distance pour Access et
SQL-Server.


"Fred" wrote in message
news:
Voilà une réponse super claire. Merci beaucoup ...

"Sylvain Lafontaine" a écrit :

C'est pour vous éviter toute une série de problèmes avec l'utilisation
des
accents français (entre autre) et du symbol euro si votre base de données
est accédé par des machines utilisant un code page windows différent
(genre
grec ou russe ou autre).

À moins que vous n'ayez un problème spécifique, arrêtez de vous poser des
questions et utilisez nvarchar() partout à la place de varchar().

--
Sylvain Lafontaine, ing.
MVP pour « Windows Live Platform »
Courriel: sylvain2009 sylvainlafontaine com (remplissez les blancs, svp.)
Consultant indépendant et programmation à distance pour Access et
SQL-Server.


"Fred" wrote in message
news:
> Bonjour,
> Je dois rajouter toute une série de tables dans une DB existante et
> dans
> cette DB, les data types utilisés sont le plus souvent nvarchar (32) ou
> 64
> ou
> 100. Pour les tables que je dois rajouter, c'est donc préférable que
> j'utilise les mêmes ? Quel est l'avantage de ces datatypes par rapport
> au
> varchar normal ? Performance ? On parle de Unicode sur msdn mais ça ne
> me
> parle pas bcp ...
> Pouvez-vous m'éclairer ?
> Merci d'avance !







Avatar
Fred
OK ! Dans les Insert into aussi ?

"Sylvain Lafontaine" a écrit :

N'oubliez pas d'utiliser le préfixe N' devant vos constantes chaîne de
caractère, genre:

Select * from MyTable where Nom = N'François'

Obligatoire seulement s'ils contiennent des codes (lettres) non-ASCII mais
vous ne perdez rien à prendre la bonne habitude de le mettre partout.

--
Sylvain Lafontaine, ing.
MVP pour « Windows Live Platform »
Courriel: sylvain2009 sylvainlafontaine com (remplissez les blancs, svp.)
Consultant indépendant et programmation à distance pour Access et
SQL-Server.


"Fred" wrote in message
news:
> Voilà une réponse super claire. Merci beaucoup ...
>
> "Sylvain Lafontaine" a écrit :
>
>> C'est pour vous éviter toute une série de problèmes avec l'utilisation
>> des
>> accents français (entre autre) et du symbol euro si votre base de données
>> est accédé par des machines utilisant un code page windows différent
>> (genre
>> grec ou russe ou autre).
>>
>> À moins que vous n'ayez un problème spécifique, arrêtez de vous poser des
>> questions et utilisez nvarchar() partout à la place de varchar().
>>
>> --
>> Sylvain Lafontaine, ing.
>> MVP pour « Windows Live Platform »
>> Courriel: sylvain2009 sylvainlafontaine com (remplissez les blancs, svp.)
>> Consultant indépendant et programmation à distance pour Access et
>> SQL-Server.
>>
>>
>> "Fred" wrote in message
>> news:
>> > Bonjour,
>> > Je dois rajouter toute une série de tables dans une DB existante et
>> > dans
>> > cette DB, les data types utilisés sont le plus souvent nvarchar (32) ou
>> > 64
>> > ou
>> > 100. Pour les tables que je dois rajouter, c'est donc préférable que
>> > j'utilise les mêmes ? Quel est l'avantage de ces datatypes par rapport
>> > au
>> > varchar normal ? Performance ? On parle de Unicode sur msdn mais ça ne
>> > me
>> > parle pas bcp ...
>> > Pouvez-vous m'éclairer ?
>> > Merci d'avance !
>>
>>
>>





Avatar
Sylvain Lafontaine
Oui, partout où vous utilisez des constantes chaîne de caractères contre des
champs de type nchar, nvarchar et ntext.

--
Sylvain Lafontaine, ing.
MVP pour « Windows Live Platform »
Courriel: sylvain2009 sylvainlafontaine com (remplissez les blancs, svp.)
Consultant indépendant et programmation à distance pour Access et
SQL-Server.


"Fred" wrote in message
news:
OK ! Dans les Insert into aussi ?

"Sylvain Lafontaine" a écrit :

N'oubliez pas d'utiliser le préfixe N' devant vos constantes chaîne de
caractère, genre:

Select * from MyTable where Nom = N'François'

Obligatoire seulement s'ils contiennent des codes (lettres) non-ASCII
mais
vous ne perdez rien à prendre la bonne habitude de le mettre partout.

--
Sylvain Lafontaine, ing.
MVP pour « Windows Live Platform »
Courriel: sylvain2009 sylvainlafontaine com (remplissez les blancs, svp.)
Consultant indépendant et programmation à distance pour Access et
SQL-Server.


"Fred" wrote in message
news:
> Voilà une réponse super claire. Merci beaucoup ...
>
> "Sylvain Lafontaine" a écrit :
>
>> C'est pour vous éviter toute une série de problèmes avec l'utilisation
>> des
>> accents français (entre autre) et du symbol euro si votre base de
>> données
>> est accédé par des machines utilisant un code page windows différent
>> (genre
>> grec ou russe ou autre).
>>
>> À moins que vous n'ayez un problème spécifique, arrêtez de vous poser
>> des
>> questions et utilisez nvarchar() partout à la place de varchar().
>>
>> --
>> Sylvain Lafontaine, ing.
>> MVP pour « Windows Live Platform »
>> Courriel: sylvain2009 sylvainlafontaine com (remplissez les blancs,
>> svp.)
>> Consultant indépendant et programmation à distance pour Access et
>> SQL-Server.
>>
>>
>> "Fred" wrote in message
>> news:
>> > Bonjour,
>> > Je dois rajouter toute une série de tables dans une DB existante et
>> > dans
>> > cette DB, les data types utilisés sont le plus souvent nvarchar (32)
>> > ou
>> > 64
>> > ou
>> > 100. Pour les tables que je dois rajouter, c'est donc préférable que
>> > j'utilise les mêmes ? Quel est l'avantage de ces datatypes par
>> > rapport
>> > au
>> > varchar normal ? Performance ? On parle de Unicode sur msdn mais ça
>> > ne
>> > me
>> > parle pas bcp ...
>> > Pouvez-vous m'éclairer ?
>> > Merci d'avance !
>>
>>
>>







Avatar
Fred
Merci

"Sylvain Lafontaine" a écrit :

Oui, partout où vous utilisez des constantes chaîne de caractères contre des
champs de type nchar, nvarchar et ntext.

--
Sylvain Lafontaine, ing.
MVP pour « Windows Live Platform »
Courriel: sylvain2009 sylvainlafontaine com (remplissez les blancs, svp.)
Consultant indépendant et programmation à distance pour Access et
SQL-Server.


"Fred" wrote in message
news:
> OK ! Dans les Insert into aussi ?
>
> "Sylvain Lafontaine" a écrit :
>
>> N'oubliez pas d'utiliser le préfixe N' devant vos constantes chaîne de
>> caractère, genre:
>>
>> Select * from MyTable where Nom = N'François'
>>
>> Obligatoire seulement s'ils contiennent des codes (lettres) non-ASCII
>> mais
>> vous ne perdez rien à prendre la bonne habitude de le mettre partout.
>>
>> --
>> Sylvain Lafontaine, ing.
>> MVP pour « Windows Live Platform »
>> Courriel: sylvain2009 sylvainlafontaine com (remplissez les blancs, svp.)
>> Consultant indépendant et programmation à distance pour Access et
>> SQL-Server.
>>
>>
>> "Fred" wrote in message
>> news:
>> > Voilà une réponse super claire. Merci beaucoup ...
>> >
>> > "Sylvain Lafontaine" a écrit :
>> >
>> >> C'est pour vous éviter toute une série de problèmes avec l'utilisation
>> >> des
>> >> accents français (entre autre) et du symbol euro si votre base de
>> >> données
>> >> est accédé par des machines utilisant un code page windows différent
>> >> (genre
>> >> grec ou russe ou autre).
>> >>
>> >> À moins que vous n'ayez un problème spécifique, arrêtez de vous poser
>> >> des
>> >> questions et utilisez nvarchar() partout à la place de varchar().
>> >>
>> >> --
>> >> Sylvain Lafontaine, ing.
>> >> MVP pour « Windows Live Platform »
>> >> Courriel: sylvain2009 sylvainlafontaine com (remplissez les blancs,
>> >> svp.)
>> >> Consultant indépendant et programmation à distance pour Access et
>> >> SQL-Server.
>> >>
>> >>
>> >> "Fred" wrote in message
>> >> news:
>> >> > Bonjour,
>> >> > Je dois rajouter toute une série de tables dans une DB existante et
>> >> > dans
>> >> > cette DB, les data types utilisés sont le plus souvent nvarchar (32)
>> >> > ou
>> >> > 64
>> >> > ou
>> >> > 100. Pour les tables que je dois rajouter, c'est donc préférable que
>> >> > j'utilise les mêmes ? Quel est l'avantage de ces datatypes par
>> >> > rapport
>> >> > au
>> >> > varchar normal ? Performance ? On parle de Unicode sur msdn mais ça
>> >> > ne
>> >> > me
>> >> > parle pas bcp ...
>> >> > Pouvez-vous m'éclairer ?
>> >> > Merci d'avance !
>> >>
>> >>
>> >>
>>
>>
>>





Avatar
Fred BROUARD
Fred a écrit :
Bonjour,
Je dois rajouter toute une série de tables dans une DB existante et dans
cette DB, les data types utilisés sont le plus souvent nvarchar (32) ou 64 ou
100. Pour les tables que je dois rajouter, c'est donc préférable que
j'utilise les mêmes ? Quel est l'avantage de ces datatypes par rapport au
varchar normal ? Performance ? On parle de Unicode sur msdn mais ça ne me
parle pas bcp ...
Pouvez-vous m'éclairer ?
Merci d'avance !




--
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 *************************
Avatar
Fred BROUARD
Effectivement le NCHAR est codé sous la forme unicode. Mais cela veut
aussi dire que toutes vos données littérales sont codées sur 2 octets
alors qu'en CHAR c'est sur 1 octet. Donc en utilisant systématiquement
du CHAR alors que cela n'est pas nécessaire vous doubler le volume de
votre base de données ce qui la rend beaucoup moins performantes.

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.

Dans quel cas le NATIONAL est-il nécessaire :
soit parce que vous avez des données de langues dont les alphabets sont
idéographique (chnois par exemple)
soit parce que vous mélangez dans le même table différentes langues avec
différents alphabets : exemple cyrillique + latin + hebreu.

A +


Fred a écrit :
Bonjour,
Je dois rajouter toute une série de tables dans une DB existante et dans
cette DB, les data types utilisés sont le plus souvent nvarchar (32) ou 64 ou
100. Pour les tables que je dois rajouter, c'est donc préférable que
j'utilise les mêmes ? Quel est l'avantage de ces datatypes par rapport au
varchar normal ? Performance ? On parle de Unicode sur msdn mais ça ne me
parle pas bcp ...
Pouvez-vous m'éclairer ?
Merci d'avance !




--
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 *************************
Avatar
Sylvain Lafontaine
> 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.

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.

--
Sylvain Lafontaine, ing.
MVP pour « Windows Live Platform »
Courriel: sylvain2009 sylvainlafontaine com (remplissez les blancs, svp.)
Consultant indépendant et programmation à distance pour Access et
SQL-Server.


"Fred BROUARD" wrote in message
news:
Effectivement le NCHAR est codé sous la forme unicode. Mais cela veut
aussi dire que toutes vos données littérales sont codées sur 2 octets
alors qu'en CHAR c'est sur 1 octet. Donc en utilisant systématiquement du
CHAR alors que cela n'est pas nécessaire vous doubler le volume de votre
base de données ce qui la rend beaucoup moins performantes.

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.

Dans quel cas le NATIONAL est-il nécessaire :
soit parce que vous avez des données de langues dont les alphabets sont
idéographique (chnois par exemple)
soit parce que vous mélangez dans le même table différentes langues avec
différents alphabets : exemple cyrillique + latin + hebreu.

A +


Fred a écrit :
Bonjour,
Je dois rajouter toute une série de tables dans une DB existante et dans
cette DB, les data types utilisés sont le plus souvent nvarchar (32) ou
64 ou 100. Pour les tables que je dois rajouter, c'est donc préférable
que j'utilise les mêmes ? Quel est l'avantage de ces datatypes par
rapport au varchar normal ? Performance ? On parle de Unicode sur msdn
mais ça ne me parle pas bcp ...
Pouvez-vous m'éclairer ?
Merci d'avance !




--
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 *************************


Avatar
Fred BROUARD
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 !

A +






--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
1 2 3