L’écriture de requêtes (2)

données : ajouter une table, des tables, des vues afin de résoudre le problème élégamment et non dans une logorrhée quéristique ! Je n’ai qu’un seul exemple à donner : imaginons qu’il faille imprimer un nombre variable d’étiquettes portant le nom du patient.

Par exemple suivant la table ci-dessous, de nom impressions : Nom Etiquettes MARTIN 3 DURAND 2 MULLER 5 LEGRAND 1 C’est à dire imprimer 3 étiquettes pour martin, 2 pour Durand, etc… Autrement dit, comment générer la table suivante en sortie : Nom
MARTIN MARTIN MARTIN
DURAND DURAND
MULLER MULLER MULLER MULLER MULLER
LEGRAND

Peu de développeurs parviennent à résoudre le problème en une seule requête. Tout simplement parce que dans le modèle de données de la base manque l’élément clef : une table des nombres, une table d’une seule colonne avec tous les nombres depuis 0 jusqu’à… suffisamment !

Ainsi en rajoutant une telle table :
CREATE TABLE T_NUM (I INT)
INSERT INTO T_NUM VALUES (0)
INSERT INTO T_NUM VALUES (1)
INSERT INTO T_NUM VALUES (2)
INSERT INTO T_NUM VALUES (3)
INSERT INTO T_NUM VALUES (4)
INSERT INTO T_NUM VALUES (5) …

La solution triviale apparaît d’une grande simplicité :
SELECT nom
FROM impressions
INNER JOIN T_NUM
ON Etiquettes < I

C’est ainsi que je vois dans la plupart des modèles de données, dans la plupart des bases que j’audite, cette absence navrante de table de nombres, de tables de dates, etc. Une explication m’est venue un jour d’un technicien : « mais nous n’avons le droit de rien rajouter à la base ! Vous vous rendrez compte ce qui risque de se passer si l’on y ajoute quelque chose ? » Aussitôt je l’ai regardé d’un air navré : « relisez donc les règles de Codd mon ami…

On y affirme que l’ajout d’un objet à la base ne perturbe en rien le fonctionnement de celle-ci. Et quand bien même vous n’auriez pas le droit moral de faire cela, que diable ! Créez vos tables dans une autre base, une base de travail que vous utiliserez pour l’occasion. Ce sera en outre portable et sans danger ! »