Une alternative a WHERE .... like '%.......'
Résolu/Fermé
Ploup
-
2 juil. 2020 à 11:30
Reivax962 Messages postés 3672 Date d'inscription jeudi 16 juin 2005 Statut Membre Dernière intervention 11 février 2021 - 3 juil. 2020 à 11:57
Reivax962 Messages postés 3672 Date d'inscription jeudi 16 juin 2005 Statut Membre Dernière intervention 11 février 2021 - 3 juil. 2020 à 11:57
A voir également:
- Une alternative a WHERE .... like '%.......'
- Coco.gg alternative - Accueil - Réseaux sociaux
- Remplaçant de Coco : quelles solutions pour tchater gratuitement en ligne ? - Accueil - Réseaux sociaux
- Zone téléchargement alternative - Accueil - Outils
- Comment voir les like sur instagram - Guide
- Alternative captvty android - Forum Logiciels
3 réponses
jordane45
Messages postés
38289
Date d'inscription
mercredi 22 octobre 2003
Statut
Modérateur
Dernière intervention
17 novembre 2024
4 703
2 juil. 2020 à 11:53
2 juil. 2020 à 11:53
Bonjour,
Tu es sur sqlserver quelle version ?
Tu es sur sqlserver quelle version ?
jordane45
Messages postés
38289
Date d'inscription
mercredi 22 octobre 2003
Statut
Modérateur
Dernière intervention
17 novembre 2024
4 703
2 juil. 2020 à 12:19
2 juil. 2020 à 12:19
Un index ne remplacera pas la façon de faire ta requête
Si tu dois utiliser un LIKE pour chercher une "portion" de text dans ta table, tu n'auras pas le choix que de continuer à faire ainsi;
Par contre, mettre des INDEX sur ses tables permets de gagner en performance.
Attention toutefois à n'en mettre que sur les champs "utils" et pas n'importe où.
( en gros, tu index que les champs sur lesquelles tu dois appliquer une clause WHERE ou pour les JOIN )
Pour créer un index :
https://docs.microsoft.com/fr-fr/sql/t-sql/statements/create-index-transact-sql?view=sql-server-ver15
Si tu dois utiliser un LIKE pour chercher une "portion" de text dans ta table, tu n'auras pas le choix que de continuer à faire ainsi;
Par contre, mettre des INDEX sur ses tables permets de gagner en performance.
Attention toutefois à n'en mettre que sur les champs "utils" et pas n'importe où.
( en gros, tu index que les champs sur lesquelles tu dois appliquer une clause WHERE ou pour les JOIN )
Pour créer un index :
https://docs.microsoft.com/fr-fr/sql/t-sql/statements/create-index-transact-sql?view=sql-server-ver15
J'ai essayé ça, tu penses que ça peut faire l'affaire ?
CREATE INDEX index1 ON MarneEtOise_panorama_Diagbox.[dbo].[TNameData] (PropertyFullName)
SELECT distinct SUBSTRING([PropertyFullName], 1, LEN([PropertyFullName]) - 12), [PropertyType], vn.Gama
FROM MarneEtOise_panorama_Diagbox.[dbo].[TNameData]
inner join @variableNameGamas vn on SUBSTRING(vn.variableName, 1, LEN(vn.variableName) - 7) like SUBSTRING([PropertyFullName], 1, LEN([PropertyFullName]) - 12)
where [PropertyFullName] like '%Description'
and LEN(variableName) > 20
and LEN(PropertyFullName) > 20
order by 1
[;]
jordane45
Messages postés
38289
Date d'inscription
mercredi 22 octobre 2003
Statut
Modérateur
Dernière intervention
17 novembre 2024
4 703
>
Ploup
2 juil. 2020 à 13:04
2 juil. 2020 à 13:04
L'index, ça se créé une seule fois.
Il ne faut pas le recréer à chaque requête....
Pour le reste, ça fait des années que je n'ai pas mis le nez dans une bdd sqlserver.
Tout est indiqué dans la doc. Je ne peux rien te dire de plus.
Il ne faut pas le recréer à chaque requête....
Pour le reste, ça fait des années que je n'ai pas mis le nez dans une bdd sqlserver.
Tout est indiqué dans la doc. Je ne peux rien te dire de plus.
Ploup
>
jordane45
Messages postés
38289
Date d'inscription
mercredi 22 octobre 2003
Statut
Modérateur
Dernière intervention
17 novembre 2024
2 juil. 2020 à 13:06
2 juil. 2020 à 13:06
ça marche merci :)
Reivax962
Messages postés
3672
Date d'inscription
jeudi 16 juin 2005
Statut
Membre
Dernière intervention
11 février 2021
1 011
3 juil. 2020 à 11:57
3 juil. 2020 à 11:57
Bonjour,
Vu ta requête, je doute qu'un index sur [PropertyFullName] puise aider en quoi que ce soit.
Petite explication sur les index.
Sous SQL Server, ils sont de deux types : les index CLUSTERED (un seul par table), et les index standards. Les premiers sont uniques parce qu'en fait ils donnent la façon dont sont écrites les données dans la table.
Par exemple, imagine un dictionnaire : c'est un index CLUSTERED sur les mots, rangés par ordre alphabétique. Tu retrouves assez rapidement un mot, sa nature, sa définition dans le dictionnaire car ils sont rangés par ordre alphabétique.
Un index non clustered c'est presque pareil mais ça ne donne pas directement les données, seulement leur adresse, comme dans une table des matières : tu retrouves rapidement ta donnée parce qu'on te donne la page où tu peux la trouver.
Au final du point de vue de l'écriture des requêtes, ces deux types d'index fonctionnent à peu près pareil.
Maintenant, reprenant ton cas avec l'analogie du dictionnaire. Si tu veux trouver tous les mots de plus de 20 lettres qui se terminent par « re »... Ordre alphabétique ou pas, tu vas devoir lire toutes les entrées... Donc l'index ne sert à rien.
Alors comment faire ?
Si tu as besoin fréquemment d'isoler les champs de type description, le mieux est encore de créer une colonne qui indique explicitement que le champ en question est de type description.
Puis en initialiser la valeur
Ensuite tu peux mettre un index sur ce champ, même si ce n'est pas optimal ça devrait être mieux que de chercher à chaque fois un nom dans une chaîne :
Et ta requête de sélection devient :
Ce n'est pas encore optimal à cause de la jointure qui elle aussi ne permet pas d'utiliser les index, si tu trouves le moyen de la faire sur des champs plutôt que des valeurs fonction des champs, ce serait mieux.
Voilà, bon courage :)
Xavier
Vu ta requête, je doute qu'un index sur [PropertyFullName] puise aider en quoi que ce soit.
Petite explication sur les index.
Sous SQL Server, ils sont de deux types : les index CLUSTERED (un seul par table), et les index standards. Les premiers sont uniques parce qu'en fait ils donnent la façon dont sont écrites les données dans la table.
Par exemple, imagine un dictionnaire : c'est un index CLUSTERED sur les mots, rangés par ordre alphabétique. Tu retrouves assez rapidement un mot, sa nature, sa définition dans le dictionnaire car ils sont rangés par ordre alphabétique.
Un index non clustered c'est presque pareil mais ça ne donne pas directement les données, seulement leur adresse, comme dans une table des matières : tu retrouves rapidement ta donnée parce qu'on te donne la page où tu peux la trouver.
Au final du point de vue de l'écriture des requêtes, ces deux types d'index fonctionnent à peu près pareil.
Maintenant, reprenant ton cas avec l'analogie du dictionnaire. Si tu veux trouver tous les mots de plus de 20 lettres qui se terminent par « re »... Ordre alphabétique ou pas, tu vas devoir lire toutes les entrées... Donc l'index ne sert à rien.
Alors comment faire ?
Si tu as besoin fréquemment d'isoler les champs de type description, le mieux est encore de créer une colonne qui indique explicitement que le champ en question est de type description.
ALTER TABLE [TNameData] ADD [is_description] bit not null default 0;
Puis en initialiser la valeur
UPDATE [TNameData] SET [is_description] = CASE WHEN [PropertyFullName] like '%Description' AND LEN(variableName) > 20 AND LEN(PropertyFullName) > 20 THEN 1 ELSE 0 END;
Ensuite tu peux mettre un index sur ce champ, même si ce n'est pas optimal ça devrait être mieux que de chercher à chaque fois un nom dans une chaîne :
CREATE INDEX idx_TNameData_is_description ON MarneEtOise_panorama_Diagbox.[dbo].[TNameData] (is_description);
Et ta requête de sélection devient :
SELECT distinct SUBSTRING([PropertyFullName], 1, LEN([PropertyFullName]) - 12), [PropertyType], vn.Gama FROM MarneEtOise_panorama_Diagbox.[dbo].[TNameData] inner join @variableNameGamas vn on SUBSTRING(vn.variableName, 1, LEN(vn.variableName) - 7) like SUBSTRING([PropertyFullName], 1, LEN([PropertyFullName]) - 12) where [is_description] = 1 order by 1
Ce n'est pas encore optimal à cause de la jointure qui elle aussi ne permet pas d'utiliser les index, si tu trouves le moyen de la faire sur des champs plutôt que des valeurs fonction des champs, ce serait mieux.
Voilà, bon courage :)
Xavier
2 juil. 2020 à 11:56