> Data > Prendre les commandes avec les prédicats SQL

Prendre les commandes avec les prédicats SQL

Data - Par Sharon L. Hoffman - Publié le 07 juin 2011
email

SQL peut traiter pratiquement tous les genres de sélection de données.

Le "Q" de SQL signifie QUERY. Et donc, le point fort de SQL est la sélection de données. Dans cet exercice, l'instruction SQL Select est la vedette, mais vous pouvez aussi définir des sélections pour spécifier quelles lignes seront affectées par une autre instruction SQL, comme Insert, Update, ou Delete.

Prendre les commandes avec les prédicats SQL

Pour désigner les données incluses dans un jeu de résultats ou traitées par une instruction SQL, on code des comparaisons appelées prédicats. Un prédicat simple compare deux valeurs, généralement une colonne de la base de données et une variable ou constante, comme ceci :

CusState = ‘CA’

On peut assimiler les prédicats à l’instruction If dans d’autres langages. Comme cette dernière, la plupart des prédicats donnent vrai (true) ou faux (false) — bien que dans certains cas (par exemple en présence de valeurs nulles), un prédicat puisse donner le résultat “unknown” (inconnu). Les prédicats servent très souvent à spécifier quelles lignes sont incluses dans une sélection de données, via une clause Where dans une instruction SQL Select, Update, ou Delete.

La clause Where d’une instruction Select détermine quelles lignes sont incluses dans la sortie (voir l’encadré “Une instruction Select passée au crible” page XX). La syntaxe de base est le mot-clé Where suivi d’un ou plusieurs prédicats :

Select * from Customer

            Where CusState = ‘CA’

Les valeurs de part et d’autre de l’opérateur de comparaison (= dans cet exemple) constituent des expressions et peuvent inclure des variables et des calculs. Les expressions sont toujours résolues avant que le prédicat soit évalué.

Pour de simples requêtes ad hoc, les valeurs codées en dur conviennent parfaitement. Mais on souhaitera souvent donner plus de souplesse à une expression. L’une des solutions les plus simples consiste à remplacer l’expression codée en dur (‘CA’) par une variable (:SelState) comme ici :

Select * from Customer

            Where CusState = :SelState

Cet exemple fait partie d’un programme RPG qui comporte du SQL imbriqué, et la variable SelState est définie ailleurs dans le programme. (Voir “Embedded SQL Jump Start,” May 2007, article ID 20878, pour une introduction aux variables hôtes et autres concepts de SQL imbriqué.)

Les parenthèses peuvent parfois faciliter la lecture de SQL, mais, dans d’autres cas, elles peuvent rendre le code moins clair. Ainsi, les deux exemples suivants donnent des résultats identiques. À vous de voir quel style de coding vous préférez et lequel vous semble le plus facile à lire.

Select * from Customer, OrdHead

            Where CusNumb = OHCust

                        and CusState = :SelState

            and OHDate >= :DateStr

            and OHDate <= :DateEnd

ou

Select * from Customer, OrdHead

Where ((CusNumb = OHCust)and (CusState = :SelState)

and ((OHDate >= :DateStr)

and (OHDate <= :DateEnd)))

Comme en algèbre, les parenthèses affectent l’ordre de traitement des prédicats. Vous pouvez connecter des prédicats en utilisant And, comme pour les comparaisons de date de cet exemple. Vous pouvez aussi utiliser Or pour connecter des prédicats et Not pour rendre négatif un prédicat. Si les critères de sélection contiennent plusieurs prédicats, ceux entre parenthèses sont évalués en premier. Les suivants par ordre de priorité sont Not, And, Or.

Téléchargez gratuitement cette ressource

5 Enjeux de Transformation Digitale

5 Enjeux de Transformation Digitale

Parfaitement alignée avec les préoccupations actuelles des entreprises, Insight propose une nouvelle offre s’appuyant sur Azure Red Hat OpenShift et les compétences reconnues de ses spécialistes de la transformation des applications. Ce Guide IT Expert détaille les 5 piliers de cette nouvelle offre inédite de modernisation et de création de valeur pour l’entreprise.

Data - Par Sharon L. Hoffman - Publié le 07 juin 2011