Je m'inscrit à nouveau en profond désaccord avec Sylvain Lafontaine (dont
les propos qu'il répète à nouveau ici me paraissent extrêmement dangereux)
« .. dont les propos ... paraissent extrêmement dangereux ... »
Extrêmement dangereux? Vous n'y allez pas un peu fort avec la chandelle?
On se prend pour qui, pour James Bond?
Je m'inscrit à nouveau en profond désaccord avec Sylvain Lafontaine (dont
les propos qu'il répète à nouveau ici me paraissent extrêmement dangereux)
« .. dont les propos ... paraissent extrêmement dangereux ... »
Extrêmement dangereux? Vous n'y allez pas un peu fort avec la chandelle?
On se prend pour qui, pour James Bond?
Je m'inscrit à nouveau en profond désaccord avec Sylvain Lafontaine (dont
les propos qu'il répète à nouveau ici me paraissent extrêmement dangereux)
« .. dont les propos ... paraissent extrêmement dangereux ... »
Extrêmement dangereux? Vous n'y allez pas un peu fort avec la chandelle?
On se prend pour qui, pour James Bond?
Sylvain Lafontaine wrote:Je m'inscrit à nouveau en profond désaccord avec Sylvain Lafontaine
(dont les propos qu'il répète à nouveau ici me paraissent extrêmement
dangereux)
« .. dont les propos ... paraissent extrêmement dangereux ... »
Extrêmement dangereux? Vous n'y allez pas un peu fort avec la chandelle?
On se prend pour qui, pour James Bond?
Dangereux car pas du tout accompagnés initialement de propos de prudence
et d'incitation à un choix réfléchi. Et je peux vous assurer qu'il est
indispensable d'adopter de la prudence lorsque l'on s'exprime sur un forum
technique public (déjà vu un grand nombre de catastrophes générées "parce
que c'était écrit dans le forum machin")
Votre correction est ainsi la bienvenue et permettra de tempérer l'opinion
de quelqu'un cherchant des pistes et découvrant cette discussion.
Sylvain Lafontaine wrote:
Je m'inscrit à nouveau en profond désaccord avec Sylvain Lafontaine
(dont les propos qu'il répète à nouveau ici me paraissent extrêmement
dangereux)
« .. dont les propos ... paraissent extrêmement dangereux ... »
Extrêmement dangereux? Vous n'y allez pas un peu fort avec la chandelle?
On se prend pour qui, pour James Bond?
Dangereux car pas du tout accompagnés initialement de propos de prudence
et d'incitation à un choix réfléchi. Et je peux vous assurer qu'il est
indispensable d'adopter de la prudence lorsque l'on s'exprime sur un forum
technique public (déjà vu un grand nombre de catastrophes générées "parce
que c'était écrit dans le forum machin")
Votre correction est ainsi la bienvenue et permettra de tempérer l'opinion
de quelqu'un cherchant des pistes et découvrant cette discussion.
Sylvain Lafontaine wrote:Je m'inscrit à nouveau en profond désaccord avec Sylvain Lafontaine
(dont les propos qu'il répète à nouveau ici me paraissent extrêmement
dangereux)
« .. dont les propos ... paraissent extrêmement dangereux ... »
Extrêmement dangereux? Vous n'y allez pas un peu fort avec la chandelle?
On se prend pour qui, pour James Bond?
Dangereux car pas du tout accompagnés initialement de propos de prudence
et d'incitation à un choix réfléchi. Et je peux vous assurer qu'il est
indispensable d'adopter de la prudence lorsque l'on s'exprime sur un forum
technique public (déjà vu un grand nombre de catastrophes générées "parce
que c'était écrit dans le forum machin")
Votre correction est ainsi la bienvenue et permettra de tempérer l'opinion
de quelqu'un cherchant des pistes et découvrant cette discussion.
L'utilisation de l'Unicode est maintenant quasi universelle
et à moins d'avoir une maudite bonne raison
contraire, votre premier réflexe doit être de l'utiliser partout; même si
vous ne pensez pas en avoir de besoin.
L'utilisation de l'Unicode est maintenant quasi universelle
et à moins d'avoir une maudite bonne raison
contraire, votre premier réflexe doit être de l'utiliser partout; même si
vous ne pensez pas en avoir de besoin.
L'utilisation de l'Unicode est maintenant quasi universelle
et à moins d'avoir une maudite bonne raison
contraire, votre premier réflexe doit être de l'utiliser partout; même si
vous ne pensez pas en avoir de besoin.
Bonjour,
Fred, j'ai un peu peur que l'utilisation de cette fonction sur un volume
de
données conséquent soit un peu couteux :-(
Cordialement
_______________________________
Philippe TROTIN
Microsoft Services France
_______________________________
"Fred BROUARD" a écrit dans le message de
groupe
de discussion :
> CREATE FUNCTION F_SUBSTITUTE (@IN VARCHAR(8000),
> @OLD VARCHAR(256),
> @NEW VARCHAR(256))
> RETURNS VARCHAR(8000)
> AS
> BEGIN
> IF @IN IS NULL RETURN NULL;
> IF @OLD IS NULL OR @OLD = ''
> OR @NEW IS NULL OR @NEW = '' RETURN @IN;
> DECLARE @I INT, @L INT;
> DECLARE @OUT VARCHAR(8000);
> DECLARE @C VARCHAR(1);
> DECLARE @POS INT;
> SET @I = 1;
> SET @L = LEN(@IN);
> SET @OUT = '';
> WHILE @I <= @L
> BEGIN
> SET @C = SUBSTRING(@IN, @I, 1);
> SET @POS = CHARINDEX(@C COLLATE French_CS_AS,
> @OLD COLLATE French_CS_AS);
> IF @POS > 0
> IF LEN(@OUT) < @POS
> SET @C = '';
> ELSE
> SET @C = SUBSTRING(@NEW, @POS, 1);
> SET @OUT = @OUT + @C;
> SET @I = @I + 1;
> END
> RETURN @OUT;
> END
> GO
> select champ1, dbo.F_SUBSTITUTE(champ1, 'þÞ', 'çè') AS NEW_CHHAMP1
> from #toto
> champ1 NEW_CHHAMP1
> ---------- --------------------
> Franþois François
> FrÞres Frères
> A +
> --
> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
> *********************http://www.datasapiens.com***********************
> Hervé REIGNOUX a écrit :
>> Bonjour,
>> Je tombe sur un os : des données venues d'un système tiers ont entraîné
>> une accentuation fantaisiste.
>> Ce problème est résolu mais je voudrais faire du ménage dans ce qui a
>> été
>> intégré.
>> Voici un exemple de ce que je veux faire sans y parvenir :
>> ------------------------------------------------
>> set NoCount ON
>> create table #toto (champ1 varchar(10))
>> insert #toto values ('Franþois')
>> insert #toto values ('FrÞres')
>> select
>> champ1,
>> cast(replace(champ1, 'þ', 'ç') as varchar(10)) as test1,
>> cast(replace(champ1, 'Þ', 'è') as varchar(10)) as test2,
>> cast(replace(cast(champ1 as varbinary(10)), cast('þ' as binary(1)),
>> cast('ç' as binary(1))) as varchar(10)) as test3,
>> cast(replace(cast(champ1 as varbinary(10)), cast('Þ' as binary(1)),
>> cast('è' as binary(1))) as varchar(10)) as test4
>> from #toto
>> select cast('Þ' as binary(1)) as 'Þ', cast('þ' as binary(1)) as 'þ'
>> drop table #toto
>> ------------------------------------------------
>> On obtient :
>> ------------------------------------------------
>> champ1 test1 test2 test3 test4
>> ---------- ---------- ---------- ---------- ----------
>> Franþois François Franèois François Franèois
>> FrÞres Frçres Frères Frçres Frères
>> Þ þ
>> ---- ----
>> 0xDE 0xFE
>> ------------------------------------------------
>> J'espère que les caractères bizarres vont bien passer sur le newsgroup
>> !
>> Si tel est le cas, vous aurez compris que je veux modifier "Franþois"
>> en
>> "François", et pas autre chose.
>> Quelqu'un peut-il m'aider ?- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
Bonjour,
Fred, j'ai un peu peur que l'utilisation de cette fonction sur un volume
de
données conséquent soit un peu couteux :-(
Cordialement
_______________________________
Philippe TROTIN
Microsoft Services France
_______________________________
"Fred BROUARD" <broua...@club-internet.fr> a écrit dans le message de
groupe
de discussion : eznIeE79HHA....@TK2MSFTNGP04.phx.gbl...
> CREATE FUNCTION F_SUBSTITUTE (@IN VARCHAR(8000),
> @OLD VARCHAR(256),
> @NEW VARCHAR(256))
> RETURNS VARCHAR(8000)
> AS
> BEGIN
> IF @IN IS NULL RETURN NULL;
> IF @OLD IS NULL OR @OLD = ''
> OR @NEW IS NULL OR @NEW = '' RETURN @IN;
> DECLARE @I INT, @L INT;
> DECLARE @OUT VARCHAR(8000);
> DECLARE @C VARCHAR(1);
> DECLARE @POS INT;
> SET @I = 1;
> SET @L = LEN(@IN);
> SET @OUT = '';
> WHILE @I <= @L
> BEGIN
> SET @C = SUBSTRING(@IN, @I, 1);
> SET @POS = CHARINDEX(@C COLLATE French_CS_AS,
> @OLD COLLATE French_CS_AS);
> IF @POS > 0
> IF LEN(@OUT) < @POS
> SET @C = '';
> ELSE
> SET @C = SUBSTRING(@NEW, @POS, 1);
> SET @OUT = @OUT + @C;
> SET @I = @I + 1;
> END
> RETURN @OUT;
> END
> GO
> select champ1, dbo.F_SUBSTITUTE(champ1, 'þÞ', 'çè') AS NEW_CHHAMP1
> from #toto
> champ1 NEW_CHHAMP1
> ---------- --------------------
> Franþois François
> FrÞres Frères
> A +
> --
> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
> *********************http://www.datasapiens.com***********************
> Hervé REIGNOUX a écrit :
>> Bonjour,
>> Je tombe sur un os : des données venues d'un système tiers ont entraîné
>> une accentuation fantaisiste.
>> Ce problème est résolu mais je voudrais faire du ménage dans ce qui a
>> été
>> intégré.
>> Voici un exemple de ce que je veux faire sans y parvenir :
>> ------------------------------------------------
>> set NoCount ON
>> create table #toto (champ1 varchar(10))
>> insert #toto values ('Franþois')
>> insert #toto values ('FrÞres')
>> select
>> champ1,
>> cast(replace(champ1, 'þ', 'ç') as varchar(10)) as test1,
>> cast(replace(champ1, 'Þ', 'è') as varchar(10)) as test2,
>> cast(replace(cast(champ1 as varbinary(10)), cast('þ' as binary(1)),
>> cast('ç' as binary(1))) as varchar(10)) as test3,
>> cast(replace(cast(champ1 as varbinary(10)), cast('Þ' as binary(1)),
>> cast('è' as binary(1))) as varchar(10)) as test4
>> from #toto
>> select cast('Þ' as binary(1)) as 'Þ', cast('þ' as binary(1)) as 'þ'
>> drop table #toto
>> ------------------------------------------------
>> On obtient :
>> ------------------------------------------------
>> champ1 test1 test2 test3 test4
>> ---------- ---------- ---------- ---------- ----------
>> Franþois François Franèois François Franèois
>> FrÞres Frçres Frères Frçres Frères
>> Þ þ
>> ---- ----
>> 0xDE 0xFE
>> ------------------------------------------------
>> J'espère que les caractères bizarres vont bien passer sur le newsgroup
>> !
>> Si tel est le cas, vous aurez compris que je veux modifier "Franþois"
>> en
>> "François", et pas autre chose.
>> Quelqu'un peut-il m'aider ?- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
Bonjour,
Fred, j'ai un peu peur que l'utilisation de cette fonction sur un volume
de
données conséquent soit un peu couteux :-(
Cordialement
_______________________________
Philippe TROTIN
Microsoft Services France
_______________________________
"Fred BROUARD" a écrit dans le message de
groupe
de discussion :
> CREATE FUNCTION F_SUBSTITUTE (@IN VARCHAR(8000),
> @OLD VARCHAR(256),
> @NEW VARCHAR(256))
> RETURNS VARCHAR(8000)
> AS
> BEGIN
> IF @IN IS NULL RETURN NULL;
> IF @OLD IS NULL OR @OLD = ''
> OR @NEW IS NULL OR @NEW = '' RETURN @IN;
> DECLARE @I INT, @L INT;
> DECLARE @OUT VARCHAR(8000);
> DECLARE @C VARCHAR(1);
> DECLARE @POS INT;
> SET @I = 1;
> SET @L = LEN(@IN);
> SET @OUT = '';
> WHILE @I <= @L
> BEGIN
> SET @C = SUBSTRING(@IN, @I, 1);
> SET @POS = CHARINDEX(@C COLLATE French_CS_AS,
> @OLD COLLATE French_CS_AS);
> IF @POS > 0
> IF LEN(@OUT) < @POS
> SET @C = '';
> ELSE
> SET @C = SUBSTRING(@NEW, @POS, 1);
> SET @OUT = @OUT + @C;
> SET @I = @I + 1;
> END
> RETURN @OUT;
> END
> GO
> select champ1, dbo.F_SUBSTITUTE(champ1, 'þÞ', 'çè') AS NEW_CHHAMP1
> from #toto
> champ1 NEW_CHHAMP1
> ---------- --------------------
> Franþois François
> FrÞres Frères
> A +
> --
> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
> *********************http://www.datasapiens.com***********************
> Hervé REIGNOUX a écrit :
>> Bonjour,
>> Je tombe sur un os : des données venues d'un système tiers ont entraîné
>> une accentuation fantaisiste.
>> Ce problème est résolu mais je voudrais faire du ménage dans ce qui a
>> été
>> intégré.
>> Voici un exemple de ce que je veux faire sans y parvenir :
>> ------------------------------------------------
>> set NoCount ON
>> create table #toto (champ1 varchar(10))
>> insert #toto values ('Franþois')
>> insert #toto values ('FrÞres')
>> select
>> champ1,
>> cast(replace(champ1, 'þ', 'ç') as varchar(10)) as test1,
>> cast(replace(champ1, 'Þ', 'è') as varchar(10)) as test2,
>> cast(replace(cast(champ1 as varbinary(10)), cast('þ' as binary(1)),
>> cast('ç' as binary(1))) as varchar(10)) as test3,
>> cast(replace(cast(champ1 as varbinary(10)), cast('Þ' as binary(1)),
>> cast('è' as binary(1))) as varchar(10)) as test4
>> from #toto
>> select cast('Þ' as binary(1)) as 'Þ', cast('þ' as binary(1)) as 'þ'
>> drop table #toto
>> ------------------------------------------------
>> On obtient :
>> ------------------------------------------------
>> champ1 test1 test2 test3 test4
>> ---------- ---------- ---------- ---------- ----------
>> Franþois François Franèois François Franèois
>> FrÞres Frçres Frères Frçres Frères
>> Þ þ
>> ---- ----
>> 0xDE 0xFE
>> ------------------------------------------------
>> J'espère que les caractères bizarres vont bien passer sur le newsgroup
>> !
>> Si tel est le cas, vous aurez compris que je veux modifier "Franþois"
>> en
>> "François", et pas autre chose.
>> Quelqu'un peut-il m'aider ?- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
Sylvain Lafontaine wrote:L'utilisation de l'Unicode est maintenant quasi universelle
(...)et à moins d'avoir une maudite bonne raison contraire, votre premier
réflexe doit être de l'utiliser partout; même si vous ne pensez pas en
avoir de besoin.
Je comprend votre argument, dans le sens où la gestion de multiples
codages avec tous les transcodages associés impose de la rigueur aux
développeurs et administrateurs, et apporte quelques lourdeurs aux
systèmes.
Cependant, en tant que développeur, je choisis TOUJOURS les technologies
en fonction du besoin, et non l'inverse.
Et le cas d'Unicode n'échappe pas à la règle, tant ce choix apporte
souvent plus de problèmes qu'il n'en résoud. Car si les solutions
proposées par le consortium Unicode sont séduisantes au premier abord,
confrontées à la réalité on est très loin d'un tableau tout rose ! Encore
une fois je vous cite l'exemple de l'Asie du sud est...
Donc pour me répéter, pour ma part je dissèque le besoin et je fais au
mieux avec les moyens que j'ai à disposition. Ce compromis est une balance
subtile entre de très nombreux critères, aussi suis-je catégoriquement
opposé à toute grande phrase sur telle technologie qui serait la panacée.
Fin de la discussion pour moi, et merci à vous d'avoir pris le temps de
compléter vos propos.
Sylvain Lafontaine wrote:
L'utilisation de l'Unicode est maintenant quasi universelle
(...)
et à moins d'avoir une maudite bonne raison contraire, votre premier
réflexe doit être de l'utiliser partout; même si vous ne pensez pas en
avoir de besoin.
Je comprend votre argument, dans le sens où la gestion de multiples
codages avec tous les transcodages associés impose de la rigueur aux
développeurs et administrateurs, et apporte quelques lourdeurs aux
systèmes.
Cependant, en tant que développeur, je choisis TOUJOURS les technologies
en fonction du besoin, et non l'inverse.
Et le cas d'Unicode n'échappe pas à la règle, tant ce choix apporte
souvent plus de problèmes qu'il n'en résoud. Car si les solutions
proposées par le consortium Unicode sont séduisantes au premier abord,
confrontées à la réalité on est très loin d'un tableau tout rose ! Encore
une fois je vous cite l'exemple de l'Asie du sud est...
Donc pour me répéter, pour ma part je dissèque le besoin et je fais au
mieux avec les moyens que j'ai à disposition. Ce compromis est une balance
subtile entre de très nombreux critères, aussi suis-je catégoriquement
opposé à toute grande phrase sur telle technologie qui serait la panacée.
Fin de la discussion pour moi, et merci à vous d'avoir pris le temps de
compléter vos propos.
Sylvain Lafontaine wrote:L'utilisation de l'Unicode est maintenant quasi universelle
(...)et à moins d'avoir une maudite bonne raison contraire, votre premier
réflexe doit être de l'utiliser partout; même si vous ne pensez pas en
avoir de besoin.
Je comprend votre argument, dans le sens où la gestion de multiples
codages avec tous les transcodages associés impose de la rigueur aux
développeurs et administrateurs, et apporte quelques lourdeurs aux
systèmes.
Cependant, en tant que développeur, je choisis TOUJOURS les technologies
en fonction du besoin, et non l'inverse.
Et le cas d'Unicode n'échappe pas à la règle, tant ce choix apporte
souvent plus de problèmes qu'il n'en résoud. Car si les solutions
proposées par le consortium Unicode sont séduisantes au premier abord,
confrontées à la réalité on est très loin d'un tableau tout rose ! Encore
une fois je vous cite l'exemple de l'Asie du sud est...
Donc pour me répéter, pour ma part je dissèque le besoin et je fais au
mieux avec les moyens que j'ai à disposition. Ce compromis est une balance
subtile entre de très nombreux critères, aussi suis-je catégoriquement
opposé à toute grande phrase sur telle technologie qui serait la panacée.
Fin de la discussion pour moi, et merci à vous d'avoir pris le temps de
compléter vos propos.
- Le fait est que l'Unicode est de plus en plus mis en avant afin de pare r à
toutes éventualités au niveau du stockage des données.
- Le fait est que l'Unicode est de plus en plus mis en avant afin de pare r à
toutes éventualités au niveau du stockage des données.
- Le fait est que l'Unicode est de plus en plus mis en avant afin de pare r à
toutes éventualités au niveau du stockage des données.
- Le fait est que l'Unicode est de plus en plus mis en avant afin de parer
à
toutes éventualités au niveau du stockage des données.
- Le fait est que l'Unicode est de plus en plus mis en avant afin de parer
à
toutes éventualités au niveau du stockage des données.
- Le fait est que l'Unicode est de plus en plus mis en avant afin de parer
à
toutes éventualités au niveau du stockage des données.
C'est ici le grand problème avec l'Unicode: comme vous le démontrez a vec
votre exemple, plusieurs personnes croient qu'avec l'Unicode, le système
prend deux fois plus de place et ira deux fois moins vite. Cependant, il ne
s'agit là pour l'essentiel qu'un d'un mythe qui n'a pas grand chose à voir
avec la réalité et même si cela était proche de la réalité, u ne division par
deux des performances ne serait toujours pas un argument suffisant pour
justifier l'utilisation de l'Ascii en lieu et place de l'Unicode.
DISCUSSION PHILOSOPHIQUE
Première des choses, la recherche de la performance en lieu et place de
l'interface conduit souvent à un résultat désastreux pour le client : ce
dernier préfère des données fiables sur un système potentiellemen t plus lent
en lieu que de données corrompues sur un système soi-disant plus rapi de.
(Souvent, ce problème se propage également sur la simplicité d'util isation
de l'interface client.). Par exemple, il est étonnant que l'un des
participants à ce fil de discussion mentionne la « dangerosité » de
l'Unicode: pour lui, des données corrompues - comme l'on retrouve trop
souvent avec l'Ascii - ce n'est pas dangereux mais un système
potentiellement plus lent l'est. À mon avis, cet ordre des priorités
devraient être changé.
Deuxièmement, l'obtention du performance supérieure est souvent inuti le.
Une augmentation du pourcentage d'utilisation moyenne du CPU de 30% vers
40%, 50% ou même 60% ne se verra pas ou sera quasi imperceptible. Ce n 'est
que lorsque l'on approche de la saturation (70% et + ) que le client
commencera à sentir la pression sur le CPU. De plus, si l'on augmente
l'utilisation du CPU par le SQL-Server, ce n'est que la fraction
correspondant à ce dernier qui sera influencé. Par exemple, si un CPU
tourne en moyenne à 30% mais que seulement 15% de cela est consacré au
SQL-Server, une division par deux de la performance de ce dernier ne fera
augmenter l'utilisation du CPU qu'à 45%.
Troisièmement, l'obtention de performance obtenue est souvent moindre q ue ce
que l'on espérait au début. Par exemple, les participants mentionnent
souvent une différence de 100% entre l'Ascii et l'Unicode mais si vous
obtenez une augmentation de 10%, vous allez être chanceux. Certaines
opérations comme l'utilisation de LIKE avec quelque chose comme "%...%" sera
probablement supérieure à 10% mais dans la plupart des cas, vous alle z être
chanceux si vous arrivez à dépasser 2 ou 3%.
Quatrièmement, la quête de la performance absolue donne souvent le r ésultat
contraire: non seulement le système ne tourne pas vraiment plus vite av ant
qu'après mais bien souvent, il tourne moins vite. Bien des programmeur s qui
recherchent à fournir les systèmes les plus rapides qui soit donnent souvent
exactement le contraire: des systèmes plus lents.
Cela est particulièrement vrai dans le cas de l'unicode versus l'ascii: le
programmeur qui perd de son temps à faire de fines distinctions entre l es
deux oublie souvent le reste, comme par exemple une analyse (approfondie ou
non) des indexes; de sorte qu'en bout de ligne, non seulement le systèm e ne
va pas 5%, 10%, 50% ou 100% plus vite mais au contraire, est deux, trois,
quatre ou cinq fois plus lent.
Comme la vitesse du CPU et la quantité de mémoire sur la carte-mère , le
temps du programmeur n'est pas illimité et celui qui perd trop de temps dans
la quête du design absolu délaisse généralement une bonne partie du reste de
son travail; avec comme résultat final un résultat bien pire que ce q u'il
aurait dû ou pû obtenir.
SECTION PLUS TECHNIQUE
Ce n'est pas 100% d'une base de données qui est consacré au stockage des
chaînes de caractères; plusieurs autres choses comme les indexes, les
pointeurs, l'espace de remplissage, etc. occupent de la place en mémoire
ainsi que sur le disque dur. Le millage peut varier mais souvent, la
différence entre un système 100% Ascii et un système 100% Unicode s era
d'environ 30%.
Pour ce qui est du CPU, le même genre de raisonnement s'applique: un CP U ne
consacre pas 100% de son temps à copier et à comparer des chaînes de
caractères et dans le cas d'une base de donnée, une multitude d'opé rations
n'ont rien ou peu à voir avec les chaînes de caractères. Même da ns le cas
de ces dernières, un doublement de l'espace mémoire utilisée ne sig nifie pas
que le temps demandé au CPU doublera; de la même façon que vous ne doublerez
pas la performance du CPU si vous doublez sa mémoire cache ou la mémo ire sur
la carte mère.
Il est difficile de mesurer adéquatement la différence de performance entre
un système tout Ascii et un autre tout Unicode mais une différence de 10% me
semble raisonnable pour la majorité des cas. Certaines opérations te lle que
l'utilisation de l'instruction LIKE "% ... %" - avec un signe de pourcent age
au début autant qu'à la fin - prendra plus de temps que 10% (20% et m ême 30%
ou plus) mais il s'agit là de l'exception et la très grande majorit é des bdd
n'utilisent pas (ou ne devraient pas utiliser) ce genre d'opération. P our
ce qui est du reste, n'espérez pas beaucoup plus que 10% et si vous
n'obtenez que 2 ou 3% de différence, n'en soyez pas surpris.
10% peut sembler beaucoup mais sur un taux moyen d'utilisation du CPU de
30%; cela correspond à une augmentation faramineuse à 33%; autant dir e rien
du tout. De plus, si vous consacrez votre temps à faire une analyse fi ne
entre l'Ascii et l'Unicode; non seulement vous n'obtiendrez probablement pas
plus que quelques points de pourcentage d'augmentation des performance -
avec l'épée de Damoclès de vous retrouvez un jour avec des données
corrompues - mais vous risquez même de vous retrouvez avec un système qui
ira en fait 100, 200 ou 300%+ plus lent parce que vous aurez délaissé des
analyses autrement plus importantes.
L'utilisation de l'ASCII (alias ANSI, codification ISO, etc.) n'est plus
aujourd'hui qu'un reliquat du passé, un fossile vivant qui devrait êt re
relégué définitivement au musée; la différence de performance d e 100% entre
l'ASCII et l'UNICODE n'est qu'un mythe qui n'a rien à voir avec la ré alité
et le temps perdu à faire des analyses fines entre l'ASCII et l'UNICODE non
seulement ne fournit pas la performance espérée au début mais bien souvent
aboutit exactement au contraire; à savoir un système plus lent parce qu'une
partie autrement plus importante de son design aura été délaissée ; sans
compter l'éternelle épée de Damoclès qui restera suspendu au dess us du
système (si vous êtes assez chanceux pour ne pas la voir tomber.
Personnellement, je l'ai vu tomber tellement souvent que j'ai arrêté de
compter voilà bien longtemps.).
Suggestion: arrêter de vous cassez la tête avec l'Ascii et mettez ce fatras
là où il se doit, au musée ou ailleurs, comme à la poubelle.
--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
"SQLpro" wrote in message
news:
On 25 sep, 12:54, "Philippe TROTIN [MS]" wr ote:
[..]
> - Le fait est que l'Unicode est de plus en plus mis en avant afin de pa rer
> à
> toutes éventualités au niveau du stockage des données.
Bien beau mais lamentable en terme de perf. Unicode = 2 octets par
car, ASCII 1 octets par car. Ce qui signifie en terme de performnace
deux fois moins rapide et surtout 2 fois plus couteux en terme de RAM,
disque, etc.
Bref de quoi pourrir les performances d'une base de données !
A +
C'est ici le grand problème avec l'Unicode: comme vous le démontrez a vec
votre exemple, plusieurs personnes croient qu'avec l'Unicode, le système
prend deux fois plus de place et ira deux fois moins vite. Cependant, il ne
s'agit là pour l'essentiel qu'un d'un mythe qui n'a pas grand chose à voir
avec la réalité et même si cela était proche de la réalité, u ne division par
deux des performances ne serait toujours pas un argument suffisant pour
justifier l'utilisation de l'Ascii en lieu et place de l'Unicode.
DISCUSSION PHILOSOPHIQUE
Première des choses, la recherche de la performance en lieu et place de
l'interface conduit souvent à un résultat désastreux pour le client : ce
dernier préfère des données fiables sur un système potentiellemen t plus lent
en lieu que de données corrompues sur un système soi-disant plus rapi de.
(Souvent, ce problème se propage également sur la simplicité d'util isation
de l'interface client.). Par exemple, il est étonnant que l'un des
participants à ce fil de discussion mentionne la « dangerosité » de
l'Unicode: pour lui, des données corrompues - comme l'on retrouve trop
souvent avec l'Ascii - ce n'est pas dangereux mais un système
potentiellement plus lent l'est. À mon avis, cet ordre des priorités
devraient être changé.
Deuxièmement, l'obtention du performance supérieure est souvent inuti le.
Une augmentation du pourcentage d'utilisation moyenne du CPU de 30% vers
40%, 50% ou même 60% ne se verra pas ou sera quasi imperceptible. Ce n 'est
que lorsque l'on approche de la saturation (70% et + ) que le client
commencera à sentir la pression sur le CPU. De plus, si l'on augmente
l'utilisation du CPU par le SQL-Server, ce n'est que la fraction
correspondant à ce dernier qui sera influencé. Par exemple, si un CPU
tourne en moyenne à 30% mais que seulement 15% de cela est consacré au
SQL-Server, une division par deux de la performance de ce dernier ne fera
augmenter l'utilisation du CPU qu'à 45%.
Troisièmement, l'obtention de performance obtenue est souvent moindre q ue ce
que l'on espérait au début. Par exemple, les participants mentionnent
souvent une différence de 100% entre l'Ascii et l'Unicode mais si vous
obtenez une augmentation de 10%, vous allez être chanceux. Certaines
opérations comme l'utilisation de LIKE avec quelque chose comme "%...%" sera
probablement supérieure à 10% mais dans la plupart des cas, vous alle z être
chanceux si vous arrivez à dépasser 2 ou 3%.
Quatrièmement, la quête de la performance absolue donne souvent le r ésultat
contraire: non seulement le système ne tourne pas vraiment plus vite av ant
qu'après mais bien souvent, il tourne moins vite. Bien des programmeur s qui
recherchent à fournir les systèmes les plus rapides qui soit donnent souvent
exactement le contraire: des systèmes plus lents.
Cela est particulièrement vrai dans le cas de l'unicode versus l'ascii: le
programmeur qui perd de son temps à faire de fines distinctions entre l es
deux oublie souvent le reste, comme par exemple une analyse (approfondie ou
non) des indexes; de sorte qu'en bout de ligne, non seulement le systèm e ne
va pas 5%, 10%, 50% ou 100% plus vite mais au contraire, est deux, trois,
quatre ou cinq fois plus lent.
Comme la vitesse du CPU et la quantité de mémoire sur la carte-mère , le
temps du programmeur n'est pas illimité et celui qui perd trop de temps dans
la quête du design absolu délaisse généralement une bonne partie du reste de
son travail; avec comme résultat final un résultat bien pire que ce q u'il
aurait dû ou pû obtenir.
SECTION PLUS TECHNIQUE
Ce n'est pas 100% d'une base de données qui est consacré au stockage des
chaînes de caractères; plusieurs autres choses comme les indexes, les
pointeurs, l'espace de remplissage, etc. occupent de la place en mémoire
ainsi que sur le disque dur. Le millage peut varier mais souvent, la
différence entre un système 100% Ascii et un système 100% Unicode s era
d'environ 30%.
Pour ce qui est du CPU, le même genre de raisonnement s'applique: un CP U ne
consacre pas 100% de son temps à copier et à comparer des chaînes de
caractères et dans le cas d'une base de donnée, une multitude d'opé rations
n'ont rien ou peu à voir avec les chaînes de caractères. Même da ns le cas
de ces dernières, un doublement de l'espace mémoire utilisée ne sig nifie pas
que le temps demandé au CPU doublera; de la même façon que vous ne doublerez
pas la performance du CPU si vous doublez sa mémoire cache ou la mémo ire sur
la carte mère.
Il est difficile de mesurer adéquatement la différence de performance entre
un système tout Ascii et un autre tout Unicode mais une différence de 10% me
semble raisonnable pour la majorité des cas. Certaines opérations te lle que
l'utilisation de l'instruction LIKE "% ... %" - avec un signe de pourcent age
au début autant qu'à la fin - prendra plus de temps que 10% (20% et m ême 30%
ou plus) mais il s'agit là de l'exception et la très grande majorit é des bdd
n'utilisent pas (ou ne devraient pas utiliser) ce genre d'opération. P our
ce qui est du reste, n'espérez pas beaucoup plus que 10% et si vous
n'obtenez que 2 ou 3% de différence, n'en soyez pas surpris.
10% peut sembler beaucoup mais sur un taux moyen d'utilisation du CPU de
30%; cela correspond à une augmentation faramineuse à 33%; autant dir e rien
du tout. De plus, si vous consacrez votre temps à faire une analyse fi ne
entre l'Ascii et l'Unicode; non seulement vous n'obtiendrez probablement pas
plus que quelques points de pourcentage d'augmentation des performance -
avec l'épée de Damoclès de vous retrouvez un jour avec des données
corrompues - mais vous risquez même de vous retrouvez avec un système qui
ira en fait 100, 200 ou 300%+ plus lent parce que vous aurez délaissé des
analyses autrement plus importantes.
L'utilisation de l'ASCII (alias ANSI, codification ISO, etc.) n'est plus
aujourd'hui qu'un reliquat du passé, un fossile vivant qui devrait êt re
relégué définitivement au musée; la différence de performance d e 100% entre
l'ASCII et l'UNICODE n'est qu'un mythe qui n'a rien à voir avec la ré alité
et le temps perdu à faire des analyses fines entre l'ASCII et l'UNICODE non
seulement ne fournit pas la performance espérée au début mais bien souvent
aboutit exactement au contraire; à savoir un système plus lent parce qu'une
partie autrement plus importante de son design aura été délaissée ; sans
compter l'éternelle épée de Damoclès qui restera suspendu au dess us du
système (si vous êtes assez chanceux pour ne pas la voir tomber.
Personnellement, je l'ai vu tomber tellement souvent que j'ai arrêté de
compter voilà bien longtemps.).
Suggestion: arrêter de vous cassez la tête avec l'Ascii et mettez ce fatras
là où il se doit, au musée ou ailleurs, comme à la poubelle.
--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
"SQLpro" <broua...@club-internet.fr> wrote in message
news:1190722863.355328.143700@19g2000hsx.googlegroups.com...
On 25 sep, 12:54, "Philippe TROTIN [MS]"<ptro...@online.microsoft.com> wr ote:
[..]
> - Le fait est que l'Unicode est de plus en plus mis en avant afin de pa rer
> à
> toutes éventualités au niveau du stockage des données.
Bien beau mais lamentable en terme de perf. Unicode = 2 octets par
car, ASCII 1 octets par car. Ce qui signifie en terme de performnace
deux fois moins rapide et surtout 2 fois plus couteux en terme de RAM,
disque, etc.
Bref de quoi pourrir les performances d'une base de données !
A +
C'est ici le grand problème avec l'Unicode: comme vous le démontrez a vec
votre exemple, plusieurs personnes croient qu'avec l'Unicode, le système
prend deux fois plus de place et ira deux fois moins vite. Cependant, il ne
s'agit là pour l'essentiel qu'un d'un mythe qui n'a pas grand chose à voir
avec la réalité et même si cela était proche de la réalité, u ne division par
deux des performances ne serait toujours pas un argument suffisant pour
justifier l'utilisation de l'Ascii en lieu et place de l'Unicode.
DISCUSSION PHILOSOPHIQUE
Première des choses, la recherche de la performance en lieu et place de
l'interface conduit souvent à un résultat désastreux pour le client : ce
dernier préfère des données fiables sur un système potentiellemen t plus lent
en lieu que de données corrompues sur un système soi-disant plus rapi de.
(Souvent, ce problème se propage également sur la simplicité d'util isation
de l'interface client.). Par exemple, il est étonnant que l'un des
participants à ce fil de discussion mentionne la « dangerosité » de
l'Unicode: pour lui, des données corrompues - comme l'on retrouve trop
souvent avec l'Ascii - ce n'est pas dangereux mais un système
potentiellement plus lent l'est. À mon avis, cet ordre des priorités
devraient être changé.
Deuxièmement, l'obtention du performance supérieure est souvent inuti le.
Une augmentation du pourcentage d'utilisation moyenne du CPU de 30% vers
40%, 50% ou même 60% ne se verra pas ou sera quasi imperceptible. Ce n 'est
que lorsque l'on approche de la saturation (70% et + ) que le client
commencera à sentir la pression sur le CPU. De plus, si l'on augmente
l'utilisation du CPU par le SQL-Server, ce n'est que la fraction
correspondant à ce dernier qui sera influencé. Par exemple, si un CPU
tourne en moyenne à 30% mais que seulement 15% de cela est consacré au
SQL-Server, une division par deux de la performance de ce dernier ne fera
augmenter l'utilisation du CPU qu'à 45%.
Troisièmement, l'obtention de performance obtenue est souvent moindre q ue ce
que l'on espérait au début. Par exemple, les participants mentionnent
souvent une différence de 100% entre l'Ascii et l'Unicode mais si vous
obtenez une augmentation de 10%, vous allez être chanceux. Certaines
opérations comme l'utilisation de LIKE avec quelque chose comme "%...%" sera
probablement supérieure à 10% mais dans la plupart des cas, vous alle z être
chanceux si vous arrivez à dépasser 2 ou 3%.
Quatrièmement, la quête de la performance absolue donne souvent le r ésultat
contraire: non seulement le système ne tourne pas vraiment plus vite av ant
qu'après mais bien souvent, il tourne moins vite. Bien des programmeur s qui
recherchent à fournir les systèmes les plus rapides qui soit donnent souvent
exactement le contraire: des systèmes plus lents.
Cela est particulièrement vrai dans le cas de l'unicode versus l'ascii: le
programmeur qui perd de son temps à faire de fines distinctions entre l es
deux oublie souvent le reste, comme par exemple une analyse (approfondie ou
non) des indexes; de sorte qu'en bout de ligne, non seulement le systèm e ne
va pas 5%, 10%, 50% ou 100% plus vite mais au contraire, est deux, trois,
quatre ou cinq fois plus lent.
Comme la vitesse du CPU et la quantité de mémoire sur la carte-mère , le
temps du programmeur n'est pas illimité et celui qui perd trop de temps dans
la quête du design absolu délaisse généralement une bonne partie du reste de
son travail; avec comme résultat final un résultat bien pire que ce q u'il
aurait dû ou pû obtenir.
SECTION PLUS TECHNIQUE
Ce n'est pas 100% d'une base de données qui est consacré au stockage des
chaînes de caractères; plusieurs autres choses comme les indexes, les
pointeurs, l'espace de remplissage, etc. occupent de la place en mémoire
ainsi que sur le disque dur. Le millage peut varier mais souvent, la
différence entre un système 100% Ascii et un système 100% Unicode s era
d'environ 30%.
Pour ce qui est du CPU, le même genre de raisonnement s'applique: un CP U ne
consacre pas 100% de son temps à copier et à comparer des chaînes de
caractères et dans le cas d'une base de donnée, une multitude d'opé rations
n'ont rien ou peu à voir avec les chaînes de caractères. Même da ns le cas
de ces dernières, un doublement de l'espace mémoire utilisée ne sig nifie pas
que le temps demandé au CPU doublera; de la même façon que vous ne doublerez
pas la performance du CPU si vous doublez sa mémoire cache ou la mémo ire sur
la carte mère.
Il est difficile de mesurer adéquatement la différence de performance entre
un système tout Ascii et un autre tout Unicode mais une différence de 10% me
semble raisonnable pour la majorité des cas. Certaines opérations te lle que
l'utilisation de l'instruction LIKE "% ... %" - avec un signe de pourcent age
au début autant qu'à la fin - prendra plus de temps que 10% (20% et m ême 30%
ou plus) mais il s'agit là de l'exception et la très grande majorit é des bdd
n'utilisent pas (ou ne devraient pas utiliser) ce genre d'opération. P our
ce qui est du reste, n'espérez pas beaucoup plus que 10% et si vous
n'obtenez que 2 ou 3% de différence, n'en soyez pas surpris.
10% peut sembler beaucoup mais sur un taux moyen d'utilisation du CPU de
30%; cela correspond à une augmentation faramineuse à 33%; autant dir e rien
du tout. De plus, si vous consacrez votre temps à faire une analyse fi ne
entre l'Ascii et l'Unicode; non seulement vous n'obtiendrez probablement pas
plus que quelques points de pourcentage d'augmentation des performance -
avec l'épée de Damoclès de vous retrouvez un jour avec des données
corrompues - mais vous risquez même de vous retrouvez avec un système qui
ira en fait 100, 200 ou 300%+ plus lent parce que vous aurez délaissé des
analyses autrement plus importantes.
L'utilisation de l'ASCII (alias ANSI, codification ISO, etc.) n'est plus
aujourd'hui qu'un reliquat du passé, un fossile vivant qui devrait êt re
relégué définitivement au musée; la différence de performance d e 100% entre
l'ASCII et l'UNICODE n'est qu'un mythe qui n'a rien à voir avec la ré alité
et le temps perdu à faire des analyses fines entre l'ASCII et l'UNICODE non
seulement ne fournit pas la performance espérée au début mais bien souvent
aboutit exactement au contraire; à savoir un système plus lent parce qu'une
partie autrement plus importante de son design aura été délaissée ; sans
compter l'éternelle épée de Damoclès qui restera suspendu au dess us du
système (si vous êtes assez chanceux pour ne pas la voir tomber.
Personnellement, je l'ai vu tomber tellement souvent que j'ai arrêté de
compter voilà bien longtemps.).
Suggestion: arrêter de vous cassez la tête avec l'Ascii et mettez ce fatras
là où il se doit, au musée ou ailleurs, comme à la poubelle.
--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
"SQLpro" wrote in message
news:
On 25 sep, 12:54, "Philippe TROTIN [MS]" wr ote:
[..]
> - Le fait est que l'Unicode est de plus en plus mis en avant afin de pa rer
> à
> toutes éventualités au niveau du stockage des données.
Bien beau mais lamentable en terme de perf. Unicode = 2 octets par
car, ASCII 1 octets par car. Ce qui signifie en terme de performnace
deux fois moins rapide et surtout 2 fois plus couteux en terme de RAM,
disque, etc.
Bref de quoi pourrir les performances d'une base de données !
A +
Unicode = 2 octets par car, ASCII 1 octets par car.
Unicode = 2 octets par car, ASCII 1 octets par car.
Unicode = 2 octets par car, ASCII 1 octets par car.
SQLpro wrote:
> Unicode = 2 octets par car, ASCII 1 octets par car.
Je reviens sur cette discussion sur une question technique bien
spécifique...
Déjà, attention car 2 octets ne suffisent plus à représenter tous les
caractères du jeux Unicode : on en a 93k (et il existe le codage UTF-32 ...)
Vu que j'ai laché SQL Server il y a quelques temps maintenant, je me
demandais si l'on avait plusieurs collation Unicode, UTF-8 et UTF-16,
comme on a sur MySQL
(http://dev.mysql.com/doc/refman/5.1/en/charset-unicode-sets.html). En
cherchant sur le technet (en particulierhttp://technet.microsoft.com/en-u s/library/ms184391.aspx) je n'ai pas
vraiment trouvé :( Quelqu'un pourrait me renseigner ?
SQLpro wrote:
> Unicode = 2 octets par car, ASCII 1 octets par car.
Je reviens sur cette discussion sur une question technique bien
spécifique...
Déjà, attention car 2 octets ne suffisent plus à représenter tous les
caractères du jeux Unicode : on en a 93k (et il existe le codage UTF-32 ...)
Vu que j'ai laché SQL Server il y a quelques temps maintenant, je me
demandais si l'on avait plusieurs collation Unicode, UTF-8 et UTF-16,
comme on a sur MySQL
(http://dev.mysql.com/doc/refman/5.1/en/charset-unicode-sets.html). En
cherchant sur le technet (en particulierhttp://technet.microsoft.com/en-u s/library/ms184391.aspx) je n'ai pas
vraiment trouvé :( Quelqu'un pourrait me renseigner ?
SQLpro wrote:
> Unicode = 2 octets par car, ASCII 1 octets par car.
Je reviens sur cette discussion sur une question technique bien
spécifique...
Déjà, attention car 2 octets ne suffisent plus à représenter tous les
caractères du jeux Unicode : on en a 93k (et il existe le codage UTF-32 ...)
Vu que j'ai laché SQL Server il y a quelques temps maintenant, je me
demandais si l'on avait plusieurs collation Unicode, UTF-8 et UTF-16,
comme on a sur MySQL
(http://dev.mysql.com/doc/refman/5.1/en/charset-unicode-sets.html). En
cherchant sur le technet (en particulierhttp://technet.microsoft.com/en-u s/library/ms184391.aspx) je n'ai pas
vraiment trouvé :( Quelqu'un pourrait me renseigner ?