Resident Load ou Preceding Load ?

Resident Load et Preceding Load permettent tous les deux d’enchaîner plusieurs étapes de transformation. Pour bien voir leur différence, nous allons résoudre exactement le même besoin avec les deux méthodes.

Nous conserverons le même besoin dans les chapitres suivants : seule la façon d’enchaîner les transformations changera.

Avec Resident, la première étape crée réellement une table dans Qlik. Une seconde instruction LOAD peut ensuite relire cette table et poursuivre les transformations.

Le mot important est « Resident » : la source du second LOAD réside déjà dans la mémoire de l’application Qlik.

// ÉTAPE 1 — création d'une table intermédiaire
VENTES_TMP:
LOAD
    ID_VENTE,
    Date#(DATE_TEXTE, 'YYYY-MM-DD') AS DATE_BRUTE,
    QUANTITE,
    PRIX_UNITAIRE,
    QUANTITE * PRIX_UNITAIRE AS CA_LIGNE
FROM [lib://Donnees/VENTES.qvd] (qvd);

// ÉTAPE 2 — on relit la table déjà chargée
VENTES:
LOAD
    ID_VENTE,
    Date(DATE_BRUTE, 'DD/MM/YYYY') AS DATE_VENTE,
    CA_LIGNE
Resident VENTES_TMP;

// ÉTAPE 3 — la table intermédiaire n'est plus utile
DROP TABLE VENTES_TMP;

Avec un Preceding Load, il n’y a pas de table intermédiaire nommée. Le résultat du LOAD inférieur est transmis directement au LOAD placé juste au-dessus.

Dans le fichier script, le LOAD supérieur est écrit en premier. Dans le flux de données, c’est pourtant le LOAD du bas qui commence le travail.

// ÉTAPE 2 — ce LOAD reçoit le résultat du LOAD inférieur
VENTES:
LOAD
    ID_VENTE,
    Date(DATE_BRUTE, 'DD/MM/YYYY') AS DATE_VENTE,
    CA_LIGNE;

// ÉTAPE 1 — celui-ci s'exécute d'abord
LOAD
    ID_VENTE,
    Date#(DATE_TEXTE, 'YYYY-MM-DD') AS DATE_BRUTE,
    QUANTITE * PRIX_UNITAIRE AS CA_LIGNE
FROM [lib://Donnees/VENTES.qvd] (qvd);

Resident et Preceding aboutissent ici au même résultat. Mais les deux solutions ne sont pas équivalentes en termes de simplicité : dans ce cas précis, le Preceding Load est le choix le plus naturel.

Ici, choisissez Preceding : le traitement est linéaire et aucune étape intermédiaire n’a besoin d’être conservée ou réutilisée.

Preceding est très pratique pour une chaîne linéaire. Resident devient particulièrement intéressant lorsque la même étape intermédiaire doit être relue, agrégée ou servir à plusieurs traitements.

Ici, matérialiser VENTES_TMP a un véritable intérêt : la même étape préparée sert plusieurs fois. On combine ici Resident et Preceding : le champ MOIS est préparé avant le GROUP BY, qui doit porter sur un nom de champ.

// VENTES_TMP a été créée au chapitre 2 :
// ID_VENTE, DATE_BRUTE, QUANTITE, PRIX_UNITAIRE, CA_LIGNE.

CA_Vente:
LOAD
    ID_VENTE,
    Sum(CA_LIGNE) AS CA_VENTE
Resident VENTES_TMP
GROUP BY ID_VENTE;

// Le LOAD inférieur prépare le champ MOIS,
// le LOAD supérieur peut alors faire GROUP BY MOIS.
CA_Mois:
LOAD
    MOIS,
    Sum(CA_LIGNE) AS CA_MOIS
GROUP BY MOIS;
LOAD
    MonthStart(DATE_BRUTE) AS MOIS,
    CA_LIGNE
Resident VENTES_TMP;

// Une fois toutes les réutilisations terminées
DROP TABLE VENTES_TMP;

Resident et Preceding ne sont pas des concurrents. Ce sont deux outils différents pour organiser les transformations d’un script Qlik.

Un même script peut parfaitement utiliser Resident à un endroit et Preceding à un autre.