Teradata: Est-il un moyen de générer de DDL à partir d'une vue ou d'une instruction select?

Générer des Instructions DDL pour les objets:

SHOW TABLE {DatabaseB}.{Table1};
SHOW VIEW {DatabaseB}.{View1};

De rupture de colonnes dans une vue:

HELP VIEW {DatabaseB}.{View1};

Cependant, sans cette capacité à créer l'objet dans la base de données cible DatabaseA votre n'ont pas beaucoup d'effet de levier. Évidemment, si l'objet existe déjà INSERT INTO SELECT ... FROM DatabaseB.Table1 ou MERGE INTO serait options que vous avez déjà exploré.

Solution Alternative

Serait-il possible d'avoir une procédure stockée créé dynamiquement créé la table basée sur le nom de la vue qui vous est fourni? L'application à l'échelle mondiale compte serait tout simplement besoin de privilèges pour exécuter la procédure. Généralement, l'utilisateur de la création de la procédure stockée aurait besoin de l'autorisation d'effectuer les actions contenues dans la procédure stockée. (Vous avez une flexibilité supplémentaire dans cette Teradata 13.10.)

Il y a quelques mises en garde avec cette approche. Vous essayez de matérialiser les points de vue qui pourraient référence de n'importe où à partir de centaines de milliards d'enregistrements. Ce ne sont pas des simple 1:1 points de vue qui sont mis sur le dessus de la table cible. En essayant de déterminer l'espace requis dans la base de données cible pour matérialiser le point de vue sera difficile. Les performances varient et peuvent varier en fonction de la complexité de la vue et les volumes de données. Ce ne sera pas un fast-path ou le bloc de données de fonctionnement optimal.

En tant qu'administrateur, je serais inquiet de cette approche par une application à l'échelle mondiale compte sans pleinement comprendre l'intention. J'espère que vous avez une ligne de communication ouverte avec le DBA(s) pour le soutien de ce système. Je suis sûr qu'il ya des raisons pour ta folie qui ne peuvent pas être divulgués ici.

Solution Possible VOLATILE TABLE

À moins que l'implicite privilège pour CRÉER la TABLE a été révoqué de l'application à l'échelle mondiale compte cette solution devrait fonctionner.

Volatils tables ne nécessitent pas de perm de l'espace. Il y a les définitions de table persistent pendant toute la durée de la session, et les données insérées dans repose sur la bobine de l'espace de l'utilisateur qui instancié.

CREATE VOLATILE TABLE {Global Application UserID}.{TableA_Copy} AS 
(
   SELECT *
     FROM {DatabaseB}.{TableA}
)
 WITH NO DATA
   NO PRIMARY INDEX
   ON COMMIT PRESERVE ROWS;

SHOW TABLE {Global Application UserID}.{TableA_Copy};

J'ai opté pour l'utilisation d'un Teradata 13.10 fonctionnalité appelée NO PRIMARY INDEX. Par défaut, CREATE TABLE COMME nous allons prendre la première colonne de la SELECT déclaration et d'en faire la PRIMARY INDEX de la table. Cela pourrait conduire à l'inclinaison et perm problèmes d'espace dans votre test en fonction des données démographiques. Vous pouvez spécifier explicitement PRIMARY INDEX sur votre propre que vous comprenez les données sous-jacentes. (Voir le DDL manuels pour plus de détails sur la syntaxe si vous êtes incertain.)

L'utilisation de ON COMMIT PRESERVE ROWS pour le but de cet exemple est sans doute superflu. Mais en réalité, si vous avez sauté toutes les données dans cette table pour les tests de cette clause serait bénéfique dans Teradata mode que les données seraient perdues immédiatement après la CREATE TABLE ou toute autre manipulation de données a été effectuée par rapport à la volatilité de la table.

OriginalL'auteur Rob Paller