Discussion :

[sekine]

Bonjour,

Je me pose quelques questions sur la pertinence de faire un index portant sur trois colonnes, dont deux d'entre elles sont des varchar. Le moteur utilisé est psotgres 8.3.

En particulier :

- L'utilisation des varchar empeche-t'elle l'utilisation de l'index (puisque le moteur doit faire un scan complet puisque les tailles des lignes sont variables) ?
- Un index sur une colonne VARCHAR est-il beaucoup moins performance qu'un index sur un type entier ? Quel serait grosso modo l'ordre de grandeur ?

Toutes vos lumieres sont les bienvenues !

[ylarvor]

je crois que tu te prends la tête pour rien, les index sont souvent des chaines de caracteres ( nom, prenom ) et les chaines sont souvent des varchar, le sgbd doit savoir s'en sortir avec ca...

[CinePhil]

Un index sur un VARCHAR est pertinent si des recherches sur cette colonne sont faites régulièrement.
Exemple :

Code :

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

1
2
3
4
5
SELECT p.per_nom, p.per_prenom
FROM personne AS p
INNER JOIN personne_participer_projet AS ppp ON p.per_id = ppp.ppp_id_personne
  INNER JOIN projet AS pr ON ppp.ppp_id_projet = pr.prj_id
WHERE pr.prj_nom = 'Cours langage SQL'

Il est ici pertinent d'avoir un index sur le nom du projet.

un index portant sur trois colonnes, dont deux d'entre elles sont des varchar.

Que sont ces trois colonnes ?
Pourquoi 2 d'entre elles sont des varchars ?

Un index sur une colonne VARCHAR est-il beaucoup moins performance qu'un index sur un type entier ?

Oui si le VARCHAR est supérieur à 3 caractères puisqu'un entier est stocké sur 4 caractères et que, sauf erreur de ma part, un VARCHAR est stocké sur autant d'octets qu'il y a de caractères + 1 octet pour la longueur de la chaîne.

Ta question laisse supposer que tu as des clés primaires, potentiellement clés étrangères dans d'autres tables, qui sont de type VARCHAR. Ca effectivement, ce n'est pas optimum pour plusieurs raisons déjà évoquées maintes fois sur ces forums.
Un identifiant sera de préférence de type entier non nul, non signé et auto incrémenté.
En Postgresql, utiliser le pseudo type serial qui crée une séquence associée à la table.

[sekine]

Un index sur un VARCHAR est pertinent si des recherche sur cette colonnes sont faites régulièrement.

Que sont ces trois colonnes ?
Pourquoi 2 d'entre elles sont des varchars ?

Ce sera le cas. La table contient deux clés k et k' hexadecimales de 32 digits de long (donc c'est vrai que je pourrais (devrais?) passer en CHAR(32) directement, mais soit) qui identifient de facon unique un compte (3eme colonne).

L'allure de ma table serait le suivant :

Code :

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

create table matable ( key_1 varchar(32), key_2 varchar(32), id_account integer , position integer );

Où ici id_account est une FK vers une autre table (la table des account donc).

Le traitement que j'ai a faire consiste a recuperer l'entier 'position' pour le triple (key_1,key_2,id_account) :

Code :

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

SELECT position from matable where key_1='XXXXX' and key_2='YYYYYY' and id_account=ZZZ;

Ta question laisse supposer que tu as des clés primaires, potentiellement clés étrangères dans d'autres tables, qui sont de type VARCHAR. Ca effectivement, ce n'est pas optimum pour plusieurs raisons déjà évoquées maintes fois sur ces forums.
Un identifiant sera de préférence de type entier non nul, non signé et auto incrémenté.
En Postgresql, utiliser le pseudo type serial qui crée une séquence associée à la table.

Par chance non. Et je ne me vois pas créer une table de clés avec une clé primaire auto-incrémentée servant de clé étrangère a ma table matable. Si ?
Ceci etant je vais essayer de me retrouver ces threads malgré tout car je pense y être confronté bientot (par exemple chercher une adresse email contenue dans une commande, dans la table des comptes d'utilisateurs)...

Merci pour ces tuyaux !