Coder les règles métier dans DB2 SQL

Je vais vous faire un aveu, j’ai pas mal hésité sur le titre de cet article. J’avais par exemple envisagé de le titrer ainsi : « You don’t know DB2 SQL ». Comme une sorte de clin d’oeil à l’un des mes auteurs préférés, Kyle Simpson, qui a écrit une série de bouquins fantastiques consacrés au langage Javascript. Mais je m’égare déjà, alors que le sujet du jour, c’est DB2 SQL, et c’est en particulier la publication de 2 nouveaux articles, que j’ai déposés ces jours ci sur XDocs400.com, et qui sont les suivants :

Ces 2 articles traitent de sujets très différents, mais ils ont en commun deux points essentiels :

  • il s’agit de requêtes SQL qui embarquent du code « métier »
  • dans les 2 cas, il s’agit, à partir d’informations transmises par la base de données et/ou un utilisateur, de générer des données qui n’existent pas telles quelles dans la base

En effet, la génération d’un tableau d’amortissement d’immobilisation est un processus très orienté « métier ». A partir de quelques données fournies en entrée telles que la valeur initiale du bien, le taux d’amortissement et la durée de l’amortissement, on va générer un tableau qui a des caractéristiques très précises (imposées par la législation), avec la contrainte supplémentaire que le jeu de données produit contient des lignes qui n’appartiennent  pas à la base de données, du fait qu’elles sont générées dynamiquement via une RCTE (Recursive Common Table Expression). Autre subtilité spécifique aux tableaux d’amortissements, et qui apporte tout son piment à l’exercice, il y a une donnée qui est  « glissante » d’une ligne sur la ligne suivante : vous l’aurez sans doute deviné, je fais référence à la VNC, ou « Valeur Nette Comptable », qui de « fin d’exercice » sur une ligne N du tableau, devient VNC de « début d’exercice » sur la ligne N+1.

Dans le cas de la détermination des périodes de vacance de biens en location, on n’a pas besoin de la récursivité, mais on devra quand même reconstituer des données ne figurant pas dans la base de données, puisque l’on souhaite identifier les périodes d’inoccupation de logements (ou d’autres biens) à partir des périodes d’occupation. Il faut donc faire « matcher » les lignes correspondant aux périodes d’occupation spécifiques à un logement. On veut en effet comparer la date de fin d’occupation d’un occupant N, avec la date de début d’occupation de l’occupant N+1. Cela nécessite de créer un lien « virtuel » entre les différentes périodes d’occupation d’un même logement, et ce lien virtuel va être généré par la clause « PARTITION BY », qui va nous servir à déclencher une rupture à chaque changement de logement. Cette notion de rupture que les développeurs RPG connaissent existe aussi en SQL DB2, mais elle est rarement employée par les développeurs SQL et c’est bien dommage.

Les techniques SQL que je présente dans ces deux articles sont quelque peu inhabituelles, elle provoquent souvent des réactions de surprise du genre :

  • « ah bon, on peut faire ça en SQL ? »

ou encore

  • « dis donc, ça donne un peu mal à la tête ton truc »

Il faut en effet un peu de temps et de pratique pour s’approprier ces techniques, mais une fois que vous les maîtrisez, c’est tout un univers de possibilités qui s’ouvre à vous. Et quand on a la chance de travailler avec une base de données aussi puissante que DB2 – base de données multi-plateformes, je crois utile de le rappeler – ce serait vraiment dommage de passer à côté de telles possibilités.