SQL vers expression booléenne

Hello les gens,
Je ne suis pas certain de poster au bon endroit mais si je peux avoir une réponse sur le forum c'est bien sur celui d'SQL j'espère.

Voila j'ai une requête avec des conditions qui devraient être dans le where et j'aurais aimé convertir la condition un peu à la manière où un :

Code:

---

IF A then B else C

---

devient:

Code:

---

((Not A) or B) AND (A or C)

---

Mes conditions à moi seraient plutôt:

Code:

---

1 2

IF (P_V_TYPE='DAOPCVM') THEN ( (YEAR(TIME_REQUEST)= L_I_ANNEE_DAOPCVM AND HEADER.TYPE='DAOPCVM') OR (YEAR(DATE_H)= L_I_ANNEE_DAOPCVM AND HEADER.TYPE='DA')) ELSE IF (P_V_TYPE='DA') THEN ((YEAR(DATE_H)= L_I_ANNEE AND HEADER.TYPE='DA') OR (YEAR(TIME_REQUEST)= L_I_ANNEE AND HEADER.TYPE='DAOPCVM'))ELSE (YEAR(DATE_H)= L_I_ANNEE AND SUBSTR(HEADER.TYPE , 1, 2)=SUBSTR(P_V_TYPE , 1, 2))

---

Ce qui pourrait être simplifié en IF A THEN B ELSE IF C THEN D ELSE E
Ce qui devient alors:

Code:

---

(not A or B) and (A or ((not C or D) and (C or E)))

---

J'ai tout bon ?

Merci pour toutes vos contributions.

Pourquoi ne pas plutôt utiliser CASE qui est fait pour ça?

Apparement le case n'est pas:
- portable
- rapide (en comparaison avec une expression booléenne)
- maintenable

Citation:

---

Envoyé par jadey

Apparement le case n'est pas:
- portable
- rapide (en comparaison avec une expression booléenne)
- maintenable

---

Ah bon ?
- portable ... Qu'est ce que vous appelez portable exactement ?
car CASE WHEN fait partie intégrante de SQL92 (Cf BNF Grammar for ISO/IEC 9075:1992 - Database Language SQL (SQL-92)), vous le trouverez sur la pluspart (voir meme l'intégralité) des SGBD.
-Rapide : Je n'ai a vrai dire jamais eu la curiosité d'analyser la différence de plan d'execution entre un CASE WHEN et une tripoté d'expressions booleennes, ca vaudrait le coup d'y jeter un oeil, mais j'ai de gros doute sur le fait que cela soit moins rapide.
- Maintenable : Cela dépend beaucoup de votre facon de coder ...

Vous definissez

Code:

---

IF A then B else C

---

Je l'aurai ecrit genre : (A.B) + (!A.C)
(A and B) or (not A and C)

Du coup, votre

Code:

---

IF A THEN B ELSE IF C THEN D ELSE E

---

Je l'aurai ecrit genre (A.B) + (C.D) + !((A.B) + (C.D)) . E

Ce qui est quand meme beaucoup moins lisible qu'un

Code:

---

1 2 3 4 5

CASE WHEN A THEN B WHEN C THEN D ELSE E END

---

Sans compter du temps passer a chercher a régulariser vos expressions booléennes, a tester leur table de vérités, et en terme de maintenance, j'aimerai bien voir ce que vous ferez lorsqu'il faudra rajouter une autre condition...

A vous de voir

Citation:

---

Envoyé par jadey

Apparement le case n'est pas:
- portable
- rapide (en comparaison avec une expression booléenne)
- maintenable

---

Je dois dire que l'argument de la maintenabilité est assez savoureux. Personnellement si je rencontrais cet enchevêtrement de OR, AND et NOT je pense qu'il me faudrait bien 15-20mn pour comprendre avec certitude ce que ça fait.
Et si c'est pour se rendre compte au final que c'est l'équivalent d'un CASE que j'aurais compris en 3 secondes, je peux dire que j'aurais de solides doutes sur la volonté du programmeur de l'avoir fait exprès pour rendre son code illisible :)

Pour ceux qui voudraient approfondir le sujet et polémiquer dessus:
http://weblogs.sqlteam.com/jeffs/arc...11/14/513.aspx
Ce qui n'est absolument pas le but de ce post. Merci.

Nous avons le droit de donner une opinion sur ce que vous cherchez a faire, puisque vous postez pour cela ?

Votre lien devoile une facon de penser et donc de coder (qui je pense ne convient deja pas a votre exemple car il s'agit de test binaire et vous etes sur un test a 3 etats) qui ne me convainc pas.

Maintenant si nos réponses sont trop polémiques, peut etre vaut il mieux poster votre demande sur le blog en question ...

Citation:

---

Nous avons le droit de donner une opinion

---

Surement, mais tu comprendras ma réticence à y donner suite pour éviter de dévier du sujet initial.

Citation:

---

Voila j'ai une requête avec des conditions qui devraient être dans le where

---

Pourquoi devraient elles etre dans le where, ou sont elles pour l'instant ?

je rajouterai simplement qu'au niveau des perfs ...si dans vos expression booléenne vous avez de jolie substring, like... ca risque de devenir marrant très vite (scannage de table presque obligatoire, je dis "presque" car vous pouvez selon le sgbd implémenter des index spécifique ).

Bref je testerai par deux fois les deux solutions avant d'avoir un avis tranché sur la question..

Cette "manière de faire" répond actuellement à mon besoin après tests. Merci pour tout vos conseils.