Discussion :

[bstevy]

Bonjour,


J'aurais besoin de votre avis concernant l'utilisation d'un between avec une chaine de caractère avec un between.

Le principe est de répondre à un besoin fonctionnel.

On me demande de ne selectionner que des identifiants tels que :
egale à '17X100A100A0001A_SIG_00000003XX' (Les XX peuvent prendre n'importe quelle valeure)
ou allant de '17X100A100A0001A_SIG_000000050X' à '17X100A100A0001A_SIG_000000056X', le X represente n'importe quelle valeure.

De ce fait, j'ai naturellement transformé ca en :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
ID like '17X100A100A0001A_SIG_00000003%'
ID BETWEEN '17X100A100A0001A_SIG_000000050' AND '17X100A100A0001A_SIG_000000057'

Or, le grand manitou qui regarde nos scripts n'est pas d'accord avec cette facon de faire sur le between. Il dit que l'utilisation d'un between sur les chaines de caracteres est faux fonctionnellement parlant.

Je ne comprends pas d'ou vient le problème.

Auriez vous fait la même chose ? Auriez vous une autre facon de faire ?
Est ce que ce resultat sera le même sur l'ensemble des SGBD ou peut il varier ?

[Razorflak]

Je ne peux pas te confirmé que sa marche de la même façon sur tous les SGBD, mais je l'utilise régulièrement sur Oracle et je n'ai jamais eu de soucis.

[Waldar]

Les comparaisons et tri de chaînes de caractères passent par l'interprétation d'une collation, définie de manière plus ou moins claire selon le SGBD, la langue de l'OS, le paramétrage de l'instance, de la base, de la session ou de la transaction.

Pour votre problème, votre première solution n'est pas tout-à-fait juste :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
select id
     , case when id like '17X100A100A0001A_SIG_00000003%'                then 1 else 0 end as test1
     , case when id like '17X100A100A0001A\_SIG\_00000003__' escape '\'' then 1 else 0 end as test2 -- la deuxième apostrophe est doublée pour mise en page forum
  from (select '17X100A100A0001AZSIGU00000003' as id       union all
        select '17X100A100A0001A_SIG_00000003999999999999' union all
        select '17X100A100A0001A_SIG_0000000310') sr;
 
id                                        test1       test2
----------------------------------------- ----------- -----------
17X100A100A0001AZSIGU00000003             1           0
17X100A100A0001A_SIG_00000003999999999999 1           0
17X100A100A0001A_SIG_0000000310           1           1

[bstevy]

Effectivement, pour le premier cas, je n'avais pas tilté que l'underscore était interpreté comme une * de regex...
Merci pour cette remarque très pertinante.


Mais en fait, dans mon cas, ca ne pose pas vraiment de problème, et c'est vraiment plus sur le deuxieme cas que je souhaiterai avoir un retour.

[aieeeuuuuu]

Bonjour,

Sur le principe, un between est correct sur une chaine de caractères. même fonctionnellement parlant : c'est tout aussi correct que de dire que l'alphabet, le C est entre le B et le D !

Par contre, comme l'a dit Waldar, c'est sensible à la collation :
Si -pour démontrer qu'il a raison- votre "manitou" passe la colonne ID en EBCDIC, alors, le code 17X100A100A0001A_SIG_00000005pz sera valide pour votre BETWEEN...
Mais... ça frise la mauvaise fois

[Yanika_bzh]

Bonjour,

Sur le principe, un between est correct sur une chaine de caractères. même fonctionnellement parlant : c'est tout aussi correct que de dire que l'alphabet, le C est entre le B et le D !

Par contre, comme l'a dit Waldar, c'est sensible à la collation :
Si -pour démontrer qu'il a raison- votre "manitou" passe la colonne ID en EBCDIC, alors, le code 17X100A100A0001A_SIG_00000005pz sera valide pour votre BETWEEN...
Mais... ça frise la mauvaise fois

ah ?? et ou placez vous '@' par rapport a '~' et '|' dans votre logique de chaine de caracteres ?

[Waldar]

Il suffit de demander au SGBD

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
select case when '@' < '~' then 1 else 0 end as "@vs~"
     , case when '@' < '|' then 1 else 0 end as "@vs|"
 
@vs~        @vs|
----------- -----------
1           1

J'ai eu ce résultat sur SQL-Server en French_CI_AS.
Même résultat sur Oracle en langage AMERICAN.

Mais différent sur PostgreSQL, en collation default (mais je n'en suis pas certain).

[Yanika_bzh]

Je demandais votre logique de comparaison, pas forcément celle de votre SGBD
Votre SGBD ne compare en aucune facon @ ou ~ mais bien leur transcodification, ce qui n a absolument rien a voir. L algèbre permet des comparaisons qui ne sont pas les memes.
Pour vous le prouver, pouvez vous me dire quelle regle de comparaison vous appliquez pour classer ces 3 termes alpha numériques :
我, 你, 他. Et demandez a votre SGBD si il est applique la même règle...

[Waldar]

Donc vous ne faites jamais de tri sur des colonnes chaînes de caractères parce que ce n'est pas logique ?

[Yanika_bzh]

Donc vous ne faites jamais de tri sur des colonnes chaînes de caractères parce que ce n'est pas logique ?

Il est evident que je fais des tris sur des colonnes de type chaine de caracteres, en connaissant pertinament la regle fonctionnelle utilisee (comparaison stricte de la valeur ASCII de chaque element de la chaine)

Je reagissais sur la tentative d explication universelle comme quoi un between appliqué a une chaine de caractere est fonctionnellement identique a un between appliqué a un nombre, ce qui est absolument faux.

[Waldar]

Il est evident que je fais des tris sur des colonnes de type chaine de caracteres, en connaissant pertinament la regle fonctionnelle utilisee (comparaison stricte de la valeur ASCII de chaque element de la chaine)

Et vous avez tort. Une comparaison et un tri c'est plus ou moins la même chose et ça dépend de la collation justement pour la raison que vous énoncez plus bas : ce ne sont pas des nombres.

Par défaut les SGBD utilisent une collation binaire, qui est modifiable.
Par exemple, sous Oracle :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
alter session set NLS_LANGUAGE = FRENCH;
-- Statement processed.
 
With SR (col) as
(
select 'E' from dual union all
select 'É' from dual union all
select 'F' from dual
)
  select col, ascii(col) as col_ascii
    from SR
order by col asc;
 
COL COL_ASCII
--- ---------
E          69
É       50057
F          70
 
alter session set NLS_LANGUAGE = AMERICAN;
-- Statement processed.
 
With SR (col) as
(
select 'E' from dual union all
select 'É' from dual union all
select 'F' from dual
)
  select col, ascii(col) as col_ascii
    from SR
order by col asc;
 
COL COL_ASCII
--- ---------
E          69
F          70
É       50057

[Yanika_bzh]

Encore une fois, utilisez mon exemple avec des caracteres non alphabetises.
Vous aurez de belles surprises.

J attends avec impatience le resultat que vous allez me procurer..

Une comparaison et un tri sont 2 choses differentes, mais vous aurez neanmoins besoin de la premiere pour effecturer le second. Cependant une comparaison n est pas forcement naturelle (cas de l algebre) et en ce qui concerne les caracteres alpha numeriques, il vous faut connaitre precisement la regle utilisee afin de faire confiance pleinement a votre processus de comparaison (ici vous impliquez la collation de votre SGBD dans la definition de la regle de comparaison, mais si pour certains besoins fonctionnels 'A'='a', dans d autre cas, ce n est pas vrai).

[aieeeuuuuu]

Il est evident que je fais des tris sur des colonnes de type chaine de caracteres, en connaissant pertinament la regle fonctionnelle utilisee (comparaison stricte de la valeur ASCII de chaque element de la chaine)

Justement, un tri sur des colonne de type chaine de caractère n'effectue pas une comparaison stricte de la valeur ASCII !!! Comme l'a indiqué Waldar, elle s'appuie sur la collation spécifiée, mais elle plus elle suit les règles de tri spécifiées pour l'unicode

Quant à votre exemple avec des caractères chinois, il suffit de spécifier... qu'il s'agit de chinois :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
WITH data AS (
	SELECT  N'我' AS t
	UNION ALL SELECT N'你'
	UNION ALL SELECT N'他'
)
SELECT t
FROM data
ORDER BY t COLLATE Chinese_PRC_CI_AS

==>
你
他
我

et en ce qui concerne les caracteres alpha numeriques, il vous faut connaitre precisement la regle utilisee afin de faire confiance pleinement a votre processus de comparaison (ici vous impliquez la collation de votre SGBD dans la definition de la regle de comparaison, mais si pour certains besoins fonctionnels 'A'='a', dans d autre cas, ce n est pas vrai).

Oui ! c'est exactement ce qu'on dit !!! Et il suffira d'utiliser la bonne collation selon les cas et les besoins.
Notez d’ailleurs vous venez vous même de comparer 'A' et 'a' !

Au final, ce que l'on attend 'un tri, c'est d'ordonner une séquence d'élément selon des règles définies. C'est aussi valable pour les nombres, et c'est bien par convention que l'on place 3 entre 2 et 4 !
Cela vous choque-t-il de classer des nombres hexadécimaux ? dans leur représentation, il y a pourtant bien des caractères alphabétiques ! mais là encore, il existe une convention.

[Yanika_bzh]

你
他
我

Votre tri ne s effectue pas sur la cle du radical (utilise pour la recherche dans un dictionnaire chinois) mais sur la transcription du pinying associe, ce qu aucun chinois ne fait pour rechercher dans un dictionnaire (un peu comme si vous traduisiez un mot francais en anglais pour le chercher dans un dictionnaire francais), du coup fonctionnellement parlant votre resultat n est pas celui attendu (t ne se trouve pas entre n et w dans le cadre d une transcription de caractere chinois)

Sur votre exemple du l hexadecimal qui justement est peut etre le meilleure exemple pour demontrer que ce qu ecrivait le premier participant :

Or, le grand manitou qui regarde nos scripts n'est pas d'accord avec cette facon de faire sur le between. Il dit que l'utilisation d'un between sur les chaines de caracteres est faux fonctionnellement parlant.

n est pas de si mauvaise foi que cela, cela depend de l expression de besoin initial.

En ce qui concerne le passage sur le fait que j utilise la comparaison alphanumerique, je n ai pas dit que la comparaison stricte du code ASCII etait la regle universelle, mais j ai utilise cet exemple pour illustrer ma premiere condition "connaitre la regle utilisee".

[aieeeuuuuu]

Votre tri ne s effectue pas sur la cle du radical .

c'est sans doute la collation qui n'est pas la bonne alors, mais j'avoue avoir du mal à la choisir, c'est du chinois pour moi :d

avec une autre collation :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
;WITH data AS (
	SELECT  N'我' AS t
	UNION ALL SELECT N'你'
	UNION ALL SELECT N'他'
)
SELECT t
FROM data
ORDER BY t COLLATE Chinese_PRC_Stroke_CI_AS

on obtient :
他
你
我

[Yanika_bzh]

c'est sans doute la collation qui n'est pas la bonne alors, mais j'avoue avoir du mal à la choisir, c'est du chinois pour moi :d

avec une autre collation :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
;WITH data AS (
	SELECT  N'我' AS t
	UNION ALL SELECT N'你'
	UNION ALL SELECT N'他'
)
SELECT t
FROM data
ORDER BY t COLLATE Chinese_PRC_Stroke_CI_AS

on obtient :
他
你
我

Cette collation utilise le nombre de traits de chaque caractere pour effectuer le tri, un peu comme si vous triiez l alphabet francais en fonction du nombre de trait dans chaque lettre...

Vous voyez donc par vous meme qu avec le meme univers d entree, votre tri sera different en fonction de la methode de comparaison (ici la collation definie) que vous utiliserez, donc lorsque vous ecriviez

Sur le principe, un between est correct sur une chaine de caractères. même fonctionnellement parlant : c'est tout aussi correct que de dire que l'alphabet, le C est entre le B et le D !

n est pas une regle fonctionnelle universelle (l alphabet zhuyin fuhao par exemple)

[aieeeuuuuu]

Vous voyez donc par vous meme qu avec le meme univers d entree, votre tri sera different en fonction de la methode de comparaison (ici la collation definie) que vous utiliserez,

Bien entendu ! et c'est d'ailleurs ce qu'on dit depuis le début de ce post. Le tri dépend de la collation...
Mais ce n'est pas pour ça qu'il est fonctionnellement faux de parler de tri pour des chaines de caractères, et par extension, d'utiliser between.

n est pas une regle fonctionnelle universelle (l alphabet zhuyin fuhao par exemple)

Je n'ai pas dit que c'était universel. en effet, j'aurai dû préciser l'alphabet français...
Mais... vous venez d’illustrer parfaitement mon exemple avec L'EBCDIC, celui où je parlais de mauvaise foi

[Yanika_bzh]

Mais... vous venez d’illustrer parfaitement mon exemple avec L'EBCDIC, celui où je parlais de mauvaise foi

La précision des règles fonctionnelles (surtout si elles ne sont pas regie par des "lois" dites "universelles") est le fondement d un développement sans encombre, en aucun cas de la mauvaise foi... Lorsque vous travaillerez avec des tiers offshore, vous y serez surement confronté.

[SQLpro]

Beaucoup de mauvaise foi dans ce que dit Yanika le breton.....

Un tri est toujours une même opération que ce soit des nombres des dates ou des chaines de caractères.
Un tri obéit à une logique de "poids" des données.

• Pour un nombre, le "poids" d'un nombre est sa valeur numérique dans le classement de - ∞ à + ∞
• Pour un temporel, le poids est son positionnement dans le temps du passé au futur.
• Pour une chaine de caractères (lettre et ponctuation seulement) le classement est celui de l'ordre alphabétique de chacun des caractères dans l'ordre séquentiel de lecture (de gauche à droite pour les langues d'origines latines et grecques, de droite à gauche pour l'arabe, l'hébreu... et de haut en bas pour certaines présentations de langages idéographiques tel que japonais...), avec certaines nuances pour les caractères diacritiques (un caractère dit "racine" décliné par exemple à l'aide d'un accent) ou la casse (majuscule, minuscule ou capitale) suivant la COLLATION utilisée.
• Pour une chaine alphanumérique (tous caractères : lettres et chiffres confondues) le classement dépend de l'encodage et de la collation.

Enfin, pour certaines langues :

• Il est nécessaire de distinguer (ou pas) la more (manière d'écrire) les éléments. C'est le cas du japonais et des écriture katakana et hiragana. On pourrait comparer cela à la subtile distinction qu'il y aurait entre une écriture scripturale (celle que l'on enseignait autrefois aux enfants avec les pleins et déliers) et une écriture plus moderne telle que celle des caractères d'imprimerie.
• Enfin, certaines langues disposent de ponctuations particulières que l'on peut confondre ou non, lorsque des comparaisons, des tris et des recherches doivent d'effectuer. C'est le cas du chinois avec les fameux espaces simples et double...

Pour les chaines purement alpha la collation règles les problèmes des caractères diacritique et la casse. En outre, toute collation dépend la langue spécifiée.

Voici les règles formelles concernant la langue française :

1) on ne tient pas compte des lettre diacritiques (accents, cédilles, ligatures...) ni de la casse (majuscules ou minuscules), sauf pour le cas des homographes (voir règle 2), et le classement respecte l'ordre des vingt-six lettres de l'alphabet de « a » à « z ».

2) Pour les homographes (mots ayant même orthographe une fois ignorée les diacritiques et la casse) on donne priorité aux minuscules sur les majuscules.
Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
CREATE TABLE T_DATA (ID INT IDENTITY PRIMARY KEY, DATA NVARCHAR(32));
GO
 
INSERT INTO T_DATA 
VALUES ('aA'), ('àÀ'), ('âÂ'), ('Aa'), ('Àà'), ('Ââ'), 
       ('cC'), ('çÇ'), ('Cc'), ('Çç'), 
       ('eE'), ('éÉ'), ('èÈ'), ('êÊ'), ('ëË'), ('Ee'), ('Éé'), ('Èè'), ('Êê'), ('Ëë'), 
       ('iI'), ('îÎ'), ('ïÏ'), 
       ('oO'), ('ôÔ'), ('Oo'), ('Ôô'), 
       ('uU'), ('ùÙ'), ('ûÛ'), ('üÜ'), ('Uu'), ('Ùù'), ('Ûû'), ('Üü'), 
       ('yY'), ('ÿŸ'), ('Yy'), ('Ÿÿ');
GO
 
SELECT *
FROM   T_DATA
ORDER BY DATA COLLATE French_CI_AI

Le résultat est le suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
ID          DATA
----------- --------------------------------
1           aA
2           àÀ
3           âÂ
4           Aa
5           Àà
6           Ââ
40          aA
41          àÀ
42          âÂ
43          Aa
44          Àà
45          Ââ
46          cC
47          çÇ
48          Cc
49          Çç
7           cC
8           çÇ
9           Cc
10          Çç
11          eE
12          éÉ
13          èÈ
14          êÊ
15          ëË
16          Ee
17          Éé
18          Èè
19          Êê
20          Ëë
50          eE
51          éÉ
52          èÈ
53          êÊ
54          ëË
55          Ee
56          Éé
57          Èè
58          Êê
59          Ëë
60          iI
61          îÎ
62          ïÏ
21          iI
22          îÎ
23          ïÏ
24          oO
25          ôÔ
26          Oo
27          Ôô
63          oO
64          ôÔ
65          Oo
66          Ôô
67          uU
68          ùÙ
69          ûÛ
70          üÜ
71          Uu
72          Ùù
73          Ûû
74          Üü
28          uU
29          ùÙ
30          ûÛ
31          üÜ
32          Uu
33          Ùù
34          Ûû
35          Üü
36          yY
37          ÿŸ
38          Yy
39          Ÿÿ
75          yY
76          ÿŸ
77          Yy
78          Ÿÿ

NOTA : ces exemples sont faits sous MS SQL Server qui respecte à la lettre (!) les collations de toutes les langues les plus utilisées (plus de 4 000 collations disponibles...)

3) Les ligatures (« æ » et « œ ») sont classés avec les lettres doubles correspondantes (« ae » et « oe »), en les discriminant toutefois par un indice de priorité particulier, pour assurer la prévisibilité absolue du classement, cet indice est à discrétion (æ étant rare et spécifique aux mots et prénoms latins comme Lætitia ou ex-æquo).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
INSERT INTO T_DATA 
VALUES ('æ'), ('œ'), ('Æ'), ('Œ'), ('ae'), ('AE'), ('oe'), ('OE');
 
SELECT *
FROM   T_DATA
ORDER BY DATA COLLATE French_CI_AI

Résultat :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
ID          DATA
----------- --------------------------------
...
45          Ââ
79          æ
81          Æ
83          ae
84          AE
46          cC
...
23          ïÏ
85          oe
86          OE
82          Œ
80          œ
24          oO
...

4) les caractères diacritiques non français sont positionnés après tous les autres caractères diacritiques français de la même lettre. Par exemple le i accent grave « ì », n'existant pas en langue française, il est placé quelque part entre le ï et le j.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
INSERT INTO T_DATA 
VALUES ('iì'), ('iÌ'), ('ìI'), ('Ìi'), ('Iì');
 
SELECT *
FROM   T_DATA
ORDER BY DATA COLLATE French_CI_AI

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
ID          DATA
----------- --------------------------------
...
23          ïÏ
87          iì
88          iÌ
89          ìI
90          Ìi
91          Iì
85          oe
...

5) Enfin, voici maintenant une règle informelle, mais utilisée par la plupart des dictionnaires : l'ordre de priorité des lettres accentuées du français la suivante : accent aigu, grave, circonflexe, tréma, cédille.

Et maintenant l'encodage...

Si la collation ne dépend pas de l'encodage, alors les valeurs caractères des numériques (de « 0 » à « 9 » ) sont situées avant les lettres :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
INSERT INTO T_DATA 
VALUES ('1A'), ('1a'), ('A1'), ('a1');
INSERT INTO T_DATA 
VALUES ('9A'), ('9a'), ('A9'), ('a9');
 
SELECT *
FROM   T_DATA
ORDER BY DATA COLLATE French_CI_AI

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
ID          DATA
----------- --------------------------------
53          1A
54          1a
57          9A
58          9a
55          A1
56          a1
59          A9
60          a9
1           aA
...

Si la collation dépend de l'encodage, alors les caractères dépendent strictement poids binaire attribué lors de l'encodage...

Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT *
FROM   T_DATA
ORDER BY DATA COLLATE SQL_EBCDIC037_CP1_CS_AS

la collation EBCDIC mélange allègrement les lettres, les chiffres et les caractères diacritiques :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
ID          DATA
----------- --------------------------------
43          Œ
41          œ
39          Ÿÿ
3           âÂ
2           àÀ
8           çÇ
12          éÉ
14          êÊ
15          ëË
13          èÈ
22          îÎ
23          ïÏ
50          ìI
6           Ââ
5           Àà
10          Çç
17          Éé
19          Êê
20          Ëë
18          Èè
51          Ìi
44          ae
1           aA
56          a1
60          a9
7           cC
11          eE
48          iì
49          iÌ
21          iI
46          oe
24          oO
40          æ
42          Æ
28          uU
36          yY
4           Aa
45          AE
55          A1
59          A9
9           Cc
16          Ee
52          Iì
25          ôÔ
26          Oo
47          OE
30          ûÛ
31          üÜ
29          ùÙ
37          ÿŸ
32          Uu
38          Yy
27          Ôô
54          1a
53          1A
58          9a
57          9A
34          Ûû
35          Üü
33          Ùù

Enfin, la collation tient même compte des autres caractères (ponctuation, mathématiques, lettre étrangères...) avec des règles particulières.... La plupart étant placés avant les lettres et les chiffres, d'autres après.

Quelques exemples :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
INSERT INTO T_DATA 
VALUES ('!A'), ('A!'), ('a!'), ('!a');
 
INSERT INTO T_DATA 
VALUES ('?A'), ('A?'), ('a?'), ('?a');
 
INSERT INTO T_DATA 
VALUES ('-A'), ('A-'), ('a-'), ('-a');
 
INSERT INTO T_DATA 
VALUES ('\A'), ('A\'), ('a\'), ('\a');
 
INSERT INTO T_DATA 
VALUES ('_A'), ('A_'), ('a_'), ('_a');
 
INSERT INTO T_DATA 
VALUES ('§A'), ('A§'), ('a§'), ('§a');
 
INSERT INTO T_DATA 
VALUES ('²A'), ('A²'), ('a²'), ('²a');
 
INSERT INTO T_DATA 
VALUES ('µA'), ('Aµ'), ('aµ'), ('µa');
 
INSERT INTO T_DATA 
VALUES ('πA'), ('Aπ'), ('πa'), ('aπ');
 
INSERT INTO T_DATA 
VALUES ('†A'), ('A†'), ('†a'), ('a†');
 
INSERT INTO T_DATA 
VALUES ('‰A'), ('A‰'), ('‰a'), ('a‰');
 
INSERT INTO T_DATA 
VALUES ('€A'), ('A€'), ('€a'), ('a€');
 
INSERT INTO T_DATA 
VALUES (N'∑A'), (N'A∑'), (N'∑a'), (N'a∑');
 
INSERT INTO T_DATA 
VALUES (N'ΩA'), (N'AΩ'), (N'Ωa'), (N'aΩ');

Résultat :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
ID          DATA
----------- --------------------------------
64          !a
61          !A
68          ?a
65          ?A
73          \A
76          \a
77          _A
80          _a
109         ∑A
111         ∑a
81          §A
84          §a
89          µA
92          µa
97          †A
99          †a
101         ‰A
103         ‰a
105         €A
107         €a
53          1A
54          1a
88          ²a
85          ²A
57          9A
58          9a
69          -A
72          -a
70          A-
71          a-
62          A!
63          a!
66          A?
67          a?
74          A\
75          a\
78          A_
79          a_
112         a∑
110         A∑
82          A§
83          a§
90          Aµ
91          aµ
100         a†
98          A†
104         a‰
102         A‰
108         a€
106         A€
55          A1
56          a1
86          A²
87          a²
59          A9
60          a9
1           aA
2           àÀ
...
45          AE
94          Aπ
96          aπ
116         aΩ
114         AΩ
7           cC
...
39          Ÿÿ
95          πa
93          πA
115         Ωa
113         ΩA

En toute logique, les caractères non sémantiques (ponctuation et symboliques par exemple), sont généralement placés avant les caractères lettres et chiffres et les autres alphabets sont situés après.

Les cas des caractères « µ » et « ∑ » peuvent paraitre étrange, mais c'est oublier qu'ils servent symboliquement (« µ » pour micro et « ∑ » pour somme...).

Bien entendu vous pouvez utiliser un classement autre que celui relevant d'une langue. Par exemple un classement binaire relevant uniquement de l'encodage spécifique au stockage de la chaine (ASCII, UNICODE, EBCDIC...).
Exemple, classement binaire UNICODE :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT *
FROM   T_DATA
ORDER BY DATA COLLATE French_BIN2

Résultat :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
ID          DATA
----------- --------------------------------
61          !A
64          !a
69          -A
72          -a
53          1A
54          1a
57          9A
58          9a
65          ?A
68          ?a
62          A!
70          A-
55          A1
59          A9
66          A?
45          AE
74          A\
78          A_
4           Aa
82          A§
86          A²
90          Aµ
94          Aπ
98          A†
102         A‰
106         A€
114         AΩ
110         A∑
9           Cc
16          Ee
52          Iì
47          OE
26          Oo
32          Uu
38          Yy
73          \A
76          \a
77          _A
80          _a
63          a!
71          a-
56          a1
60          a9
67          a?
1           aA
75          a\
79          a_
44          ae
83          a§
87          a²
91          aµ
96          aπ
100         a†
104         a‰
108         a€
116         aΩ
112         a∑
7           cC
11          eE
21          iI
49          iÌ
48          iì
24          oO
46          oe
28          uU
36          yY
81          §A
84          §a
85          ²A
88          ²a
89          µA
92          µa
5           Àà
6           Ââ
42          Æ
10          Çç
18          Èè
17          Éé
19          Êê
20          Ëë
51          Ìi
27          Ôô
33          Ùù
34          Ûû
35          Üü
2           àÀ
3           âÂ
40          æ
8           çÇ
13          èÈ
12          éÉ
14          êÊ
15          ëË
50          ìI
22          îÎ
23          ïÏ
25          ôÔ
29          ùÙ
30          ûÛ
31          üÜ
37          ÿŸ
43          Œ
41          œ
39          Ÿÿ
93          πA
95          πa
97          †A
99          †a
101         ‰A
103         ‰a
105         €A
107         €a
113         ΩA
115         Ωa
109         ∑A
111         ∑a

NOTA : pour obtenir la liste des collations de MS SQL Server, utilisez la requête suivantes (les collations MS SQL Server sont toutes indépendantes de l'encodage utilisé) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT * FROM sys.fn_helpcollations()

La version 2012 de SQL Server compte 3 885 collations différentes pour 101 langues et dialectes (16 pour le chinois...) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
WITH T AS 
(
SELECT *, REPLACE(description, '-100', '') AS new_desc
FROM   sys.fn_helpcollations()
)
SELECT DISTINCT SUBSTRING(new_desc, 1, CHARINDEX(',', new_desc)-1)
FROM   T
ORDER  BY 1

ENFIN : peu de SGBDR gèrent correctement les collations. Pour MySQL et PostGreSQL c'est plus que navrant, les développeurs étant essentiellement US ne s'intéressent donc pas aux problématique d'accents et plus généralement de caractères diacritiques. Ces deux SGBDR sont incapable de gérer correctement des recherches, des tris et des unicités en tenant compte ou non des accents; Pour Oracle, c'est aussi très limité, Oracle ayant donné dans un truc imbitable appelé NLS qui supporte mal aussi la gestion des caractères diacritiques.
Seul MS SQL Server s'en sort très bien et c'est ce qui en fait son poids fort lors des comparaisons pour des sites web internationaux par exemple....

À lire sur les collations avec MySQL : http://blog.developpez.com/sqlpro/p1..._grand_folklor

À lire sur les collations avec PostGreSQL : http://blog.developpez.com/sqlpro/fi...lit%C3%A9s.pdf (page 10)

A +

[Yanika_bzh]

J attendais avec impatience l intervention du Sieur SQL PRO

Un tri obéit à une logique de "poids" des données.

Je suis totallement d accord
La logique de "poids" de donnees est aussi la comparaison appliquee pour ce dit tri.
Reste a definir les regle de calcul des poids de donnees

Focalisons nous sur le cas de la chaine de caracteres puisque c est sur celle ci que nous débattons.
J avais deja lu votre billet sur la collation et les langues (a decharge du MySQL si ma memoire est bonne) avec un petit paragraphe sur la langue japonaise et chinoise. Entre parenthese, vous ne devez certainement pas maitriser les fondements de cette derniere car vous parliez de notion d espace dans la grammaire chinoise, chose qui n existe evidemment pas.

La collation est une solution a un tri pour autant qu elle colle a l expression de besoin initial.
aieeeuuuuu a démontré qu a partir du meme univers initial, le tri obtenu est different d'une collation a l'autre. Or si je veux rechercher un mot chinois dans mon dictionnaire chinois (sans pinyin) aucune des ces regles ne correspond a celle que je devrais mettre en place pour retrouver ce fameux mot.

j avais ecrit

Une comparaison et un tri sont 2 choses differentes, mais vous aurez neanmoins besoin de la premiere pour effectuer le second. Cependant une comparaison n est pas forcement naturelle (cas de l algebre) et en ce qui concerne les caracteres alpha numeriques, il vous faut connaitre precisement la regle utilisee afin de faire confiance pleinement a votre processus de comparaison (ici vous impliquez la collation de votre SGBD dans la definition de la regle de comparaison, mais si pour certains besoins fonctionnels 'A'='a', dans d autre cas, ce n est pas vrai).

C est bien ce que vous demontrez dans votre billet

En ce qui concerne les collations chinoises sous Sql SERVER je ne les connais pas, je m etais arrete au
Chinese_PRC_CI_AS -> basee sur la transcription pinyin
Chinese_PRC_Stroke_CI_AS -> Basee sur la transcription du nombre de traits (mode simplifie)
Chinese_Taiwan_Bopomofo_CI_AS -> basee sur la transcription de l alphabet zhuyin fuhao
Chinese_Taiwan_Stroke_CI_AS -> Basee sur la transcription du nombre de traits (mode traditionnel)

Je ne suis pas au courant des 12 autres collations possibles, mais je serai tres interesse de les connaitre (cela peut toujours etre utile)

Ceci dit la question de départ ne portait pas sur un langage parle, mais bel et bien d un codage interne d une application dont nous n avions pas connaissance de sa construction et donc de sa logique de classement.

Cordialement,

Et Bonne Annee ! 新年快乐。