Discussion :

[BYALI]

Bonjour
j'ai des requetes que je stock dans un champs de 255 caractères pour les utiliser.

toutes les requêtes sont courtes à part celle la que je suis sur qu'elle peut être réécrite autrement pour rentrer dans ce champs.

Code :

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

1
2
3
select * from factv where date_m>'01/01/2014'   
and (client in(select code from c_client where portefeuille like 'DRGE%' or portefeuille like 'DRHP%' or portefeuille like 'D-C-E%') 
       or origine in(select bl from blv where client in(select code from c_client where portefeuille like 'DRGE%' or portefeuille like 'DRHP%' or portefeuille like 'D-C-E%')))

est ce qu'il y a une possibilité?

[pcaboche]

Le titre est trompeur. C'est pas une "optimisation d'une requête longue" (une requête qui prend trop de temps à s'exécuter).

C'est juste que vous faites des trucs bizarres à stocker du code SQL dans une table...

j'ai des requetes que je stock dans un champs de 255 caractères pour les utiliser.

Y'en a qui cherchent les problèmes...

est ce qu'il y a une possibilité?

Oui (entre autres) :

Code :

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

1
2
ALTER TABLE [Ma_super_table_de_requetes_sql]
ALTER COLUMN CodeSql NVARCHAR(MAX)

Même en essayant d' "optimiser" (les perfs, pas la taille du code), ça fait 292 caractères :

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
SELECT F.*
FROM
(    
    select code
    from c_client
    where portefeuille like 'DRGE%'
    or portefeuille like 'DRHP%'
    or portefeuille like 'D-C-E%'
) C
LEFT JOIN blv B
    ON (B.client = C.code)
INNER JOIN factv F
    ON (F.client = C.code
    OR F.origine = B.bl)
where F.date_m > '2014-01-01'

[BYALI]

C'est juste que vous faites des trucs bizarres à stocker du code SQL dans une table...

avant de juger, poser la question pourquoi je stocke;
j'ai une application de transfert de données entre 2 sites distants, sauf que je filtre les données pour certains sites.
je dois stocker le filtre dans une base, car c'est variant d'un site à l'autre.


pour la proposition de l'optimisation; ça marche pas il y a des doublons

SELECT F.*
FROM
(
select code
from c_client
where portefeuille like 'DRGE%'
or portefeuille like 'DRHP%'
or portefeuille like 'D-C-E%'
) C
LEFT JOIN blv B
ON (B.client = C.code)
INNER JOIN factv F
ON (F.client = C.code
OR F.origine = B.bl)
where F.date_m > '2014-01-01'

[pcaboche]

avant de juger, poser la question pourquoi je stocke;
j'ai une application de transfert de données entre 2 sites distants, sauf que je filtre les données pour certains sites.
je dois stocker le filtre dans une base, car c'est variant d'un site à l'autre.

J'ai déjà vu des gens stocker des requêtes SQL dans une base de données.

Ce qu'on en retient :
- c'est rarement une bonne idée pour tout un tas de raisons (y compris : performance et sécurité) et il y a souvent d'autres manières de procéder
- dans les rares cas où ça se justifierait, la personne ayant implémenté cette solution ne se serait pas limité à 255 caractères

(et pourquoi pas 140 caractères, qu'on puisse tweeter le code ? )

pour la proposition de l'optimisation; ça marche pas il y a des doublons

Et bien sûr, vous ne savez pas :
1. pourquoi il y a des doublons ? (je vous laisse un indice : vous avez 2 conditions vérifiées en même temps)
2. comment les supprimer ?

Vous ne comprenez pas pourquoi j'évite de faire 2 fois la même sous-requête et en quoi la requête est fondamentalement différente ?
Vous pensez que j'ai le pouvoir d'executer des requêtes à distance sur vos données, pour pouvoir vous servir la solution du premier coup et sur un plateau doré ?

Ben non, et plutôt que de chercher, c'est tellement plus simple de dire...

"Ça marche PAAAAAAAAAAAS !"

Et de toute façon, la solution oblige à ajouter un peu de code, donc ça ne rentrera pas dans vos 255 caractères...

[iberserk]

Pour gagner des caractères (mais c'est clairement un faux problème ici) vous pouvez penser créer des vues SQL entre vos différentes tables afin d'éviter les IN avec sous select etc...

[pcaboche]

Pour gagner des caractères (mais c'est clairement un faux problème ici) vous pouvez penser créer des vues SQL entre vos différentes tables afin d'éviter les IN avec sous select etc...

Il y a plein de solutions envisageables :
- écrire des vues
- écrire une procédure stockée et faire appel à celle-ci (dangereux)
- vu que c'est pour tranférer des données entre différents sites, faire des réplications et mettre des filtres sur certaines tables

Cependant :
- certaines de ces "solutions" sont à éviter
- il y a certainement d'autres contraintes qu'on ne connait pas
- comme tu l'as dit, le problème de la longueur du code, "c'est un faux problème"

Pour paraphraser Marvin dans "Le guide du voyageur galactique" :
"J'ai un million d'idées, elles mennent toutes à une mort certaine".

[BYALI]

Merci pour vos orientations,
je devrais revoir l'écriture des jointures.
c'est compliqué de vous expliquer pourquoi j'ai choisi d'écrire la requete sur un champs à 255 caractère.

Mais je tacherai à prendre en considération vos orientations.

Merci pour vos réponses