Dans l'environnement SAS© Viya™, le langage FedSQL est le standard pour interagir avec les données. S'il excelle pour traduire des requêtes standards (SQL ANSI) vers les bases de données (Pass-Through Implicite), il montre ses limites dès que l'on souhaite utiliser des fonctionnalités propriétaires du moteur de base de données, comme des fonctions géospatiales ou le parsing de JSON.
Cet article se penche sur une technique puissante : le Pass-Through Explicite, illustré ici par l'extraction de données JSON stockées dans PostgreSQL.
Le Défi : Les limites de la traduction automatique
Lorsque vous écrivez une requête FedSQL classique, SAS© tente de la traduire en SQL natif pour l'envoyer à la base de données. Cependant, si votre requête contient des opérateurs que SAS© ne connaît pas, la traduction échoue ou SAS© tente de rapatrier toutes les données pour les traiter localement.
Prenons le cas de PostgreSQL, qui possède d'excellentes capacités de traitement JSON via des opérateurs spécifiques comme -> ou ->>. Si vous utilisez ces symboles directement dans une requête FedSQL standard, vous obtiendrez une erreur de syntaxe, car l'interpréteur SAS© ne les reconnaît pas.
La Solution : Le Pass-Through Explicite
La solution consiste à utiliser la clause CONNECTION TO. Cette syntaxe crée un "tunnel" direct vers la base de données.
Le principe est simple : Tout ce qui est écrit à l'intérieur de la clause de connexion est invisible pour l'interpréteur SAS©/FedSQL. SAS© se contente de prendre la chaîne de caractères et de la passer telle quelle au moteur PostgreSQL.
Syntaxe Générale
Cas Concret : Analyse de données JSON
Imaginons une table PostgreSQL contenant une colonne data_json stockant des informations brutes. Nous voulons extraire un champ spécifique de ce JSON et calculer une agrégation, sans jamais charger le JSON brut dans CAS (ce qui serait lourd et inutile).
Le Code
Analyse Technique
Voici pourquoi cette approche est optimale :
L'Invisibilité pour l'interpréteur (Black Box) :
L'interpréteur FedSQL ne "voit" pas les opérateurs -> et ->>. Il ne tente donc pas de les valider. S'il les voyait, il renverrait une erreur de syntaxe car ces symboles n'existent pas dans le standard SQL ANSI supporté par SAS©. C'est PostgreSQL qui reçoit la chaîne brute et l'interprète.
Utilisation des Opérateurs Natifs :
-> : Récupère un champ d'objet JSON sous forme d'objet JSON.
->> : Récupère un champ d'objet JSON sous forme de texte (String).
Ces opérateurs permettent de naviguer dans la structure hiérarchique des données directement au niveau du moteur de stockage.
Performance et "Data Movement" :
C'est le point crucial.
Sans Pass-Through Explicite : Il faudrait charger toute la table (avec le JSON lourd) dans CAS, puis essayer de parser le texte avec des fonctions SAS© complexes. Cela consomme énormément de mémoire et de réseau.
Avec Pass-Through Explicite : PostgreSQL effectue l'extraction JSON et l'agrégation ("lourde"). Le serveur CAS ne reçoit que le résultat final : une petite table de synthèse ("petite table prête à l'emploi").
Le Pass-Through Explicite via CONNECTION TO est indispensable pour les utilisateurs avancés de SAS© Viya™. Il permet de briser les barrières du langage FedSQL standard pour exploiter 100% des capacités de vos bases de données (parsing JSON, XML, indexation spécifique), tout en minimisant drastiquement les mouvements de données vers le serveur CAS.
