Netezza - réutilise le code SQL commun sur plusieurs requêtes de manière DRY?

Question

Est-il possible avec les requêtes Netezza d'inclure des fichiers sql (qui contiennent un code sql spécifique) ou ce n'est pas la bonne façon d'utiliser?

Voici un exemple.

J'ai un code sql commun (permet de dire common.sql) qui crée une table temporaire et doit être utilisé dans plusieurs autres requêtes (permet de dire analysis1.sql, analysis2.sql etc.) -. Du point de vue de la gestion de code, il est assez écrasant de maintenir si le code dans common.sql est répété à travers les nombreuses autres requêtes. Y a-t-il une façon DRY de le faire - quelque chose comme #include <common.sql> à partir des autres requêtes pour appeler le code réutilisé common.sql?

Answer 1

Y compris les fichiers sql n'est pas la bonne façon de le faire. Si vous souhaitez persister avec cela, vous pouvez utiliser un préprocesseur comme cpp ou même php pour assembler les fichiers pour vous et avoir un processus de construction pour générer ceux finis. Cependant, du point de vue de la maintenabilité, il est préférable de créer des vues et des fonctions pour le contenu réutilisable. Notez que cela peut poser des problèmes d'optimisation, de sorte que les requêtes de grande taille sont souvent la solution.

Answer 2

Je suis d'accord, vues, fonctions (valeurs de table si nécessaire) ou plus probable: les procédures stockées est la voie à suivre. Nous avons eu beaucoup de chance en laissant les procédures stockées générer des modèles de code complexes mais reproductibles à la volée en fonction des paramètres d'entrée et des métadonnées sur les tables en cours de traitement. Exemple: toutes les tables ont une 'contrainte unique' (qui n'est pas vraiment unique, mais cela n'a pas d'importance puisqu'elle n'est pas appliquée dans Netezza) qui a un nom fixe de UBK_ [nomtable] UBK est utilisé comme un «signal» pour la procédure stockée identifiant les colonnes de la clé BusinessKey pour une table de dimension type «style kimball» classique. Le fournisseur de services peut ensuite appliquer les lignes 'entrantes' à la table cible simplement en recevant le nom de la table cible et une table 'stage' contenant tous les mêmes noms de colonnes et types de données.

D'autres exemples pourraient être un SP qui prend un nom de table et trois arguments, chacun avec une chaîne, de, colonnes et fait un 'pivot de style excel' avec group-by sur les colonnes du premier argument et utilise le second argument de faire un 'select distinct' pour générer de nouveaux noms de colonne pour les colonnes pivotées, et fait une 'somme' sur la colonne dans le troisième argument dans une table cible vous spécifiez le nom pour ...

Pouvez-vous suis moi? Je pense que l'outil de ligne de commande nzsql peut être capable de faire un 'include', mais une combinaison de 'procédures stockées de blocs de construction' solides et perl/python et/ou un outil ETL sera probablement un meilleur choix