Discussion :

[GT4485]

Bonjour.
Soit une base SQLite sous iOS, et une table de plusieurs dizaines de milliers de lignes comportant une colonne "code postal" de 5 caractères, et 4 colonnes de 1 caractère, chacune pouvant avoir seulement 2 ou 3 valeurs, comme un code sexe.
Les valeurs de ces 5 colonnes ne changent quasi jamais. Ces 5 colonnes sont très fréquemment utilisées dans des clauses WHERE, mais pas forcément toutes en même temps.
Pour une question de performance, il me semble nécessaire d'utiliser un/des index. Mais lesquels ?
1) Créer un index sur chaque colonne, mais avec seulement 2 ou 3 valeurs différentes, ceci a-t-il un sens ?
2) Créer un index sur les 4 colonnes, mais sera-t-il utilisé si la clause WHERE ne spécifie que la valeur de certaines d'entre elles ?
3) Concaténer physiquement les 4 colonnes de 1 caractère en une seule colonne, construire un index sur cette colonne agrégée, et utiliser une clause WHERE avec un LIKE ? Outre que cette solution n'est pas très propre, SQLite utilise-t-il l'index quand un LIKE est spécifié ?
4) Créer un seul index sur le code postal et les 4 colonnes de 1 caractère, et utiliser une clause WHERE avec un LIKE ? SQLite utilise-t-il l'index quand un LIKE est spécifié ?
5) Autre ?
Merci de votre aide,
Gilbert

[Delphi-ne]

Je ne sais pas si SqlLite gère les vues. Sinon une vue par colonne.
A défaut effectivement un index par colonne. Il faut oublier les like qui ne sont pas reconnus par les index.

[SergioMaster]

Bonjour,

mon avis : outre bien évidement un index primaire unique numérique ? un index sur le code postal est justifiable.

Une table peut peut-être se justifier pour certaines de ces colonnes d'un caractère ? auquel cas je verrais bien un contrainte de référence (qui construira un index ) sinon, non, je ne crois pas que l'ajout d'un index sur ces colonnes soit très "optimiseur" quoique vu le volume .... c'est vrai que l'on peut se poser des questions !

[Bloon]

Bonjour,

Il faut également se poser la question des combinaisons de critères réellement pertinentes (et éventuellement interdire les autres par un contrôle applicatif). Ensuite, il faut créer les index en fonction des combinaisons autorisées. Pour avoir une idée de ce qui se passe, tu peux faire des explain query plan select * from matable where critere1 = "" and critere2 = "" et voir ainsi quels index sont utilisés en fonction des combinaisons de critères.

Bloon

[escartefigue]

D'une façon générale, un index peut filtrant n'a pas d'intérêt pour les recherches, mais il peut avoir un intérêt s'il est couvrant.

Donc a priori ne créez pas d'index pour les colonnes n'ayant que deux ou trois valeurs possibles, mais par exception, ça peut présenter un intérêt.

Concaténer les différentes colonnes est la solution à ne surtout pas choisir, ce serait un viol de la 1NF et une redondance d'information avec tous les risques que cela comporte.
Faire des recherches vous obligerait à utiliser des OR multiples, rarement indexables et LIKE, s'il commence par '%' n'est pas indexable non plus !