Tentative de simplification d'une requête

[StringBuilder]

Bonjour,

J'ai les tables suivantes :

PRO (produit)
codsoc (société)
codpro (code produit)
codzn15 (code produit stock)
coduni (code unité)

PRC (assortiment client)
codsoc (société)
typtie (type de tiers)
sigfou (sigle du tiers)
codpro (code produit)
codzn2 (code produit à préparer)

Le lien est le suivant :
Pour un même CODSOC, pour TYPTIE = 'CLI', on a dans PRC la liste des CODPRO produits disponibles à la vente pour le client SIGFOU. Le PRC.CODZN2 est le produit à préparer dans le camion lorsque le client commande le produit. Le PRO.CODZN15 est le produit stock. L'unité d'un produit est PRo.CODUNI.

Par exemple :
- Je stock du lait en palettes (PRO.CODZN15)
- Je le gère dans mon article sous forme de bouteilles de 1 litre (PRO.CODPRO et PRC.CODPRO)
- Le client me l'achète en pack de 6 bouteilles (PRC.CODZN2)

Maintenant, j'ai la demande suivante, pour une application de prévisions de vente :

On doit faire des prévisions de vente sur le produit à préparer, sauf si ce dernier est un colis ou unité, à ce moment on prend le produit stock.
Le produit est retourné sans la première lettre.

Pour savoir si une unité est acceptable pour l'outils de prévisions de vente, il faut que :
- Soit l'unité commence par P, B ou D et qu'elle soit différente de PI

PRC.CODZN2 n'est pas toujours rempli, à ce moment je dois prendre PRO.CODZN15
Le produit n'est pas forcément assorti chez le client (il y a d'autres tables qui jouent dans la requête, et je peux avoir des produits qui ne sont pas dans PRC, à ce moment je dois prendre PRO.CODZN15

J'ai donc fait cette requête (Oracle, désolé pour la syntaxe DECODE) :

Code :

1
2
3
4
5
 
SELECT p1.codsoc, r.sigfou, SUBSTR(decode(nvl(p2.coduni, ' '), ' ', pro.codzn15, 'PI', pro.codzn15, decode(substr(p2.coduni, 1, 1), 'P', prc.codzn2, 'D', prc.codzn2, 'B', prc.codzn2, pro.codzn15)),2,9)
FROM pro p1
LEFT OUTER JOIN prc r ON r.codsoc = p1.codsoc AND r.r.typtie = 'CLI' AND r.codpro = p1.codpro
LEFT OUTER JOIN pro p2 ON p2.codsoc = r.codsoc AND p2.codpro = r.codpro

Le DECODE me semble très barbare.
Vous voyez une solution magique pour simplifier la chose ?

[CinePhil]

Ne connaissant pas encore l'idiôme Oracle, je vais juste répondre sur ce que je ferais sur ça :

Pour savoir si une unité est acceptable pour l'outils de prévisions de vente, il faut que :
- Soit l'unité commence par P, B ou D et qu'elle soit différente de PI

Ça veut dire que tu fais une restriction sur les lignes retournées à celles dont le coduni commence par P, B ou D et ne commence pas pas PI ?

Code :

1
2
WHERE SUBSTRING(coduni FROM 1 FOR 1) IN ('P', 'B', 'D')
    AND SUBSTRING(coduni FROM 1 FOR 2) <> 'PI'

Et pour ceci :

Le produit est retourné sans la première lettre.

Code :

SUBSTRING(la_colonne FROM 2 FOR (CHARACTER_LENGTH(la_colonne) - 1))

À voir si Oracle accepte cette syntaxe normalisée.

[StringBuilder]

Hmmm, en effet, c'est pas plus compliqué que ça... Et ça simplifie le DECODE, qui est pas très lisible...

Je vais voir dans quelle mesure je peux implémenter la restriction dans le WHERE.

[Waldar]

Envoyé par CinePhil

À voir si Oracle accepte cette syntaxe normalisée.

Non, c'est la fonction SUBSTR.

[lola06]

@CinePhil : Par curiosité il n'est pas mieux d'utiliser un LIKE et NOT LIKE dans le where plutôt qu'un SUBSTR ?

Code :

1
2
WHERE ( coduni LIKE 'P%' OR coduni LIKE 'D%' coduni LIKE 'B%' )
AND coduni NOT LIKE 'PI%'

[lola06]

Envoyé par CinePhil

Et pour ceci :

Code :

SUBSTRING(la_colonne FROM 2 FOR (CHARACTER_LENGTH(la_colonne) - 1))

À voir si Oracle accepte cette syntaxe normalisée.

Tu peux simplifier normalement en :

Code :

SUBSTR(la_colonne,2)

[StringBuilder]

Envoyé par lola06

@CinePhil : Par curiosité il n'est pas mieux d'utiliser un LIKE et NOT LIKE dans le where plutôt qu'un SUBSTR ?

Code :

Je préfère LIKE 'X%' car lorsque le % se trouve en fin de pattern, le LIKE utilise les index.

Alors que je ne suis pas sûr du tout que SUBSTR (même s'il commence au caractère 1) puisse le faire.
D'autant que je trouve bien plus lisible un LIKE qu'un SUBSTR, qui demande à lire à la fois la chaîne recherchée et l'endroit de la recherche.

[CinePhil]

Effectivement, le LIKE est plus simple et probablement plus performant pour la raison évoquée par stringbuilder.