Discussion :

[Lert Sarin]

Bonjour,

ma question est plutôt simple et la réponse le sera surement tout autant, mais je n'ai pas trouvé avec l'outil de recherche.

Mes cours de SGBD sont plutôt loin, mais il me semble que la recherche dans une table avec une chaine de caractère, ce n'est pas ce qu'il y a de mieux.

Ma première idée pour optimiser cela, c'est de garder seulement l'empreinte de la chaine (checksum ou autre) et convertir ma chaine à la volée à chaque fois que je dois la chercher.

Je ne peux pas croire que ce sujet n'ai pas déjà été traiter et n'ai pas déjà une solution. Mais je n'ai pas trouvé.

exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
TABLE
ID | ref     | donnee
--------------------------------
01 | toto1   | truc super utile
01 | toto2   | truc super utile
 
 
select *
from TABLE
where ref = "toto1";

Remplacer par :

Code :

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

1
2
3
4
5
6
7
8
9
10
TABLE
ID | ref        | donnee
--------------------------------
01 | f1a7b39b   | truc super utile
01 | 2881f096   | truc super utile
 
 
select *
from TABLE
where ref = f1a7b39b;

après, je ne sais pas si rechercher de l'hexa, c'est mieu que de chercher une chaine, mais bon...

Merci d'avance.

[aieeeuuuuu]

Bonjour,

mais il me semble que la recherche dans une table avec une chaine de caractère, ce n'est pas ce qu'il y a de mieux

si votre table est correctement indexée (en l'occurence sur la colonne ref), votre requête sera parfaitement performante (une fois que vous aurez remplacé le SELECT * par la liste des colonne dont vous avez besoin.


ce sont plutôt les recherches de type WHERE UneColonne LIKE '%quelquechose' qui posent des problèmes de performance, car aucun index ne peut être utilisé. Dans ce cas il existe des solutions plus adaptées, mais ça ne semble pas être votre besoin.

[Lert Sarin]

Merci pour votre réponse.

Si je comprend bien, tout dépend de l'index et non de la donnée en elle même. ce qui entraine une seconde question :

Je ne suis pas particulièrement familier avec cette histoire d'index. Je vais donc me renseigner. Mais au passage, la "qualité" (je ne trouve pas d'autre mot) de l'index dépend-elle de la nature de la donnée ?

pour simplifier :

texte >moins bien que> suite de caractère simple >moins bien que> chiffre ...etc...

ou bien cela se vaut ?
ou peut-être que cela dépend du SGBD ?

[Rams7s]

Comme bien souvent, ça dépend les SGBD.
Par exemple ce que dit aieuu ne tient pas avec oracle.

Code :

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

1
2
3
4
5
6
7
8
 
create table tmp as select dbms_random.string('u',10) as vc, level as n, lpad(level,45,'x') as padding from dual connect by level<1e4;
create index tmp_ind on tmp(vc);
 
select * from tmp where vc like 'AAAA%';
select * from tmp where vc like 'AA%';
select * from tmp where vc like 'A%';
select * from tmp where vc like 'A%' or vc like 'AB%';

http://sqlfiddle.com/#!4/de1f5/5
Les 3 premiers selects vont utiliser l'index pour aller chercher les données, et ce malgré la présence du select * et du %.
Ceci car le nombre de lignes ramenées est faible par rapport au nombre de lignes totales estimées, et aussi parce que Oracle sait faire un like sur un index cela.

Pour le type de donnée, ça se vaut à peu près (pour Oracle). Disons que si c'est le plus gros problème de tout le développement, en général on arrive à vivre avec.

[tatayo]

Cela ne contredit pas ce que dit aieeeuuuuu.
Ce sont les recherches de type '%kekchose' qui n'utilisent pas les indexes:

Code SQL :

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

1
2
 
SELECT * FROM tmp WHERE vc LIKE '%AAAA';

Tatayo.

[aieeeuuuuu]

oui, je parle bien du cas ou le % est en début de chaine...

si vous cherchez dans un dictionnaire les mots commençant par la lettre B, vous allez vous rendre à la page des B, et lire tous les mots jusqu'au C.

Si en revanche vous devez chercher tous les mots finissant par B, vous allez vous taper tout le dictionnaire, de A jusqu'à Z !

Enfin, le select * peut aussi rendre l'index non pas inutilisable, mais contre performant, car après avoir trouvé les lignes dans l'index qui correspondent aux critères, il faut ensuite aller lire la table pour récupérer les données de toutes les autres colonnes.
à partir de votre exemple, si on lance ces deux requêtes :

Code :

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

1
2
3
 
select *  from tmp where vc like 'A%' or vc like 'B%';
select vc from tmp where vc like 'A%' or vc like 'B%';

La première n'utilise pas l'index, la deuxième si...

[Lert Sarin]

J'ai suffisamment de notion en SGBD pour savoir que les "SELECT *" est a proscrire. Même si je ne savais pas que le comportement changeait aussi radicalement que cela pour une requête simple.

Cela dit, Ma recherche concerne une chaine entière. Donc au vue de vos commentaires, je me pose trop de questions...

Merci pour l'aide apportée