CREATE DYNAMIC TABLE¶

Syntaxe¶

CREATE [ OR REPLACE ] [ TRANSIENT ] DYNAMIC TABLE [ IF NOT EXISTS ] <name> (
    -- Column definition
    <col_name> <col_type>
      [ [ WITH ] MASKING POLICY <policy_name> [ USING ( <col_name> , <cond_col1> , ... ) ] ]
      [ [ WITH ] PROJECTION POLICY <policy_name> ]
      [ [ WITH ] TAG ( <tag_name> = '<tag_value>' [ , <tag_name> = '<tag_value>' , ... ] ) ]
      [ COMMENT '<string_literal>' ]
      [ WITH CONTACT ( <purpose> = <contact_name> [ , <purpose> = <contact_name> ... ] ) ]

    -- Additional column definitions
    [ , <col_name> <col_type> [ ... ] ]

  )
  TARGET_LAG = { '<num> { seconds | minutes | hours | days }' | DOWNSTREAM }
  WAREHOUSE = <warehouse_name>
  [ INITIALIZATION_WAREHOUSE = <warehouse_name> ]
  [ REFRESH_MODE = { AUTO | FULL | INCREMENTAL } ]
  [ INITIALIZE = { ON_CREATE | ON_SCHEDULE } ]
  [ CLUSTER BY ( <expr> [ , <expr> , ... ] ) ]
  [ DATA_RETENTION_TIME_IN_DAYS = <integer> ]
  [ MAX_DATA_EXTENSION_TIME_IN_DAYS = <integer> ]
  [ COMMENT = '<string_literal>' ]
  [ COPY GRANTS ]
  [ [ WITH ] ROW ACCESS POLICY <policy_name> ON ( <col_name> [ , <col_name> ... ] ) ]
  [ [ WITH ] AGGREGATION POLICY <policy_name> [ ENTITY KEY ( <col_name> [ , <col_name> ... ] ) ] ]
  [ [ WITH ] TAG ( <tag_name> = '<tag_value>' [ , <tag_name> = '<tag_value>' , ... ] ) ]
  [ REQUIRE USER ]
  [ IMMUTABLE WHERE ( <expr> ) ]
  [ BACKFILL FROM ]
  [ EXECUTE AS USER <user_name>
    [ USE SECONDARY ROLES { ALL | NONE | <role> [ , ... ] } ]
  ]
  [ ROW_TIMESTAMP = { TRUE | FALSE } ]
  AS <query>

Syntaxe des variantes¶

CREATE OR ALTER DYNAMIC TABLE <name> (
  -- Column definition
  <col_name> <col_type>
    [ COLLATE '<collation_specification>' ]
    [ COMMENT '<string_literal>' ]

  -- Additional column definitions
  [ , <col_name> <col_type> [ ... ] ]
  )
  TARGET_LAG = { '<num> { seconds | minutes | hours | days }' | DOWNSTREAM }
  WAREHOUSE = <warehouse_name>
  [ REFRESH_MODE = FULL | INCREMENTAL | AUTO ]
  [ IMMUTABLE WHERE ( <expr> ) ]
  [ CLUSTER BY ( <expr> [ , <expr> , ... ] ) ]
  [ DATA_RETENTION_TIME_IN_DAYS = <integer> ]
  [ MAX_DATA_EXTENSION_TIME_IN_DAYS = <integer> ]
  [ COMMENT = '<string_literal>' ]
  [ ROW_TIMESTAMP = { TRUE | FALSE } ]

CREATE DYNAMIC TABLE <name> FROM BACKUP SET <backup_set> IDENTIFIER '<backup_id>'

CREATE [ OR REPLACE ] [ TRANSIENT ] DYNAMIC TABLE <name>
  CLONE <source_dynamic_table>
        [ { AT | BEFORE } ( { TIMESTAMP => <timestamp> | OFFSET => <time_difference> | STATEMENT => <id> } ) ]
  [
    COPY GRANTS
    TARGET_LAG = { '<num> { seconds | minutes | hours | days }' | DOWNSTREAM }
    WAREHOUSE = <warehouse_name>
    EXECUTE AS USER <user_name>
      USE SECONDARY ROLES { ALL | NONE | <role> [ , ... ] }
  ]

CREATE [ OR REPLACE ] DYNAMIC ICEBERG TABLE <name> (
  -- Column definition
  <col_name> <col_type>
    [ [ WITH ] MASKING POLICY <policy_name> [ USING ( <col_name> , <cond_col1> , ... ) ] ]
    [ [ WITH ] TAG ( <tag_name> = '<tag_value>' [ , <tag_name> = '<tag_value>' , ... ] ) ]
    [ COMMENT '<string_literal>' ]

  -- Additional column definitions
  [ , <col_name> <col_type> [ ... ] ]

)
TARGET_LAG = { '<num> { seconds | minutes | hours | days }' | DOWNSTREAM }
WAREHOUSE = <warehouse_name>
[ EXTERNAL_VOLUME = '<external_volume_name>' ]
[ CATALOG = 'SNOWFLAKE' ]
[ BASE_LOCATION = '<optional_directory_for_table_files>' ]
[ ICEBERG_VERSION = <integer> ]
[ REFRESH_MODE = { AUTO | FULL | INCREMENTAL } ]
[ INITIALIZE = { ON_CREATE | ON_SCHEDULE } ]
[ CLUSTER BY ( <expr> [ , <expr> , ... ] ) ]
[ DATA_RETENTION_TIME_IN_DAYS = <integer> ]
[ MAX_DATA_EXTENSION_TIME_IN_DAYS = <integer> ]
[ COMMENT = '<string_literal>' ]
[ COPY GRANTS ]
[ [ WITH ] ROW ACCESS POLICY <policy_name> ON ( <col_name> [ , <col_name> ... ] ) ]
[ [ WITH ] TAG ( <tag_name> = '<tag_value>' [ , <tag_name> = '<tag_value>' , ... ] ) ]
[ REQUIRE USER ]
[ EXECUTE AS USER <user_name>
  [ USE SECONDARY ROLES { ALL | NONE | <role> [ , ... ] } ]
]
AS <query>

Paramètres requis¶

name

Indique l’identificateur (c’est-à-dire le nom) de la table dynamique ; doit être unique pour le schéma dans lequel la table dynamique est créée.

De plus, l’identificateur doit commencer par un caractère alphabétique et ne peut pas contenir d’espaces ou de caractères spéciaux à moins que toute la chaîne d’identificateur soit délimitée par des guillemets doubles (p. ex. "My object"). Les identificateurs entre guillemets doubles sont également sensibles à la casse.

Pour plus de détails, voir Exigences relatives à l’identificateur.

TARGET_LAG = { num { seconds | minutes | hours | days } | DOWNSTREAM }

Spécifie le décalage de la table dynamique :

'num seconds | minutes | hours | days'

Spécifie le délai maximum pendant lequel le contenu de la table dynamique doit être décalé par rapport aux mises à jour des tables de base.

Par exemple :

• Si les données de la table dynamique ne doivent pas être décalées de plus de 5 minutes, indiquez 5 minutes.

• Si les données de la table dynamique ne doivent pas être décalées de plus de 5 heures, indiquez 5 hours.

La durée doit être d’au moins 60 secondes. Si la table dynamique dépend d’une autre table dynamique, la latence cible minimum doit être supérieure ou égale à la latence cible de la table dynamique dont elle dépend.

DOWNSTREAM

Spécifie que la table dynamique ne doit être actualisée que lorsque les tables dynamiques qui en dépendent sont actualisées.

Pour plus d’informations sur la manière dont la latence cible affecte la fréquence et les coûts d’actualisation, voir Identifier la latence cible appropriée.

WAREHOUSE = warehouse_name

Spécifie le nom de l’entrepôt qui fournit les ressources de calcul pour l’actualisation de la table dynamique.

Vous devez utiliser un rôle doté du privilège USAGE sur cet entrepôt pour pouvoir créer la table dynamique. Pour connaître les limites et d’autres informations, voir Privilèges permettant de créer une table dynamique.

Pour obtenir des conseils sur le choix d’un entrepôt pour des performances d’actualisation optimales, voir Ajuster la configuration de votre entrepôt.

AS query

Spécifie la requête dont les résultats doivent être contenus dans la table dynamique.

Paramètres facultatifs¶

INITIALIZATION_WAREHOUSE = warehouse_name

Spécifie un entrepôt à utiliser pour toutes les initialisations et réinitialisations des tables dynamiques.

Si ce paramètre n’est pas inclus dans l’instruction CREATE DYNAMIC TABLE, la table dynamique utilise l’entrepôt qui est spécifié par le paramètre WAREHOUSE requis pour toutes les actualisations.

Vous devez utiliser un rôle doté du privilège USAGE sur cet entrepôt pour pouvoir créer la table dynamique. Pour connaître les limites et d’autres informations, voir Privilèges permettant de créer une table dynamique.

TRANSIENT

Indique que la table est transitoire.

Comme les tables dynamiques permanents, les tables dynamiques transitoires existent jusqu’à ce qu’elles soient explicitement supprimées et sont accessibles à tout utilisateur disposant des privilèges appropriés. Les tables dynamiques transitoires ne conservent pas les données dans un stockage Fail-safe, ce qui permet de réduire les coûts de stockage, en particulier pour les tables fréquemment actualisés. En raison de ce niveau de durabilité réduit, les tables dynamiques transitoires sont idéales pour les données transitoires qui n’ont pas besoin du même niveau de protection et de récupération des données que les tables permanentes.

Par défaut : aucune valeur. Si une table dynamique n’est pas déclarée comme TRANSIENT, elle est permanente.

REFRESH_MODE = { AUTO | FULL | INCREMENTAL }

Spécifie le mode d’actualisation de la table dynamique.

Cette propriété ne peut pas être modifiée après la création de la table dynamique. Pour modifier la propriété, créez à nouveau la table dynamique avec une commande CREATE OR REPLACE DYNAMIC TABLE.

AUTO

Lorsque le mode d’actualisation est AUTO, le système tente d’appliquer une actualisation incrémentielle par défaut. Cependant, lorsque l’actualisation incrémentielle n’est pas prise en charge ou risque de ne pas fonctionner correctement, la table dynamique sélectionne automatiquement l’actualisation complète à la place. Pour plus d’informations, voir Modes d’actualisation des tables dynamiques et Sélectionner un mode d’actualisation.

Pour déterminer le mode le mieux adapté à votre casse, expérimentez les modes d’actualisation et les recommandations automatiques. Pour un comportement cohérent entre les versions de Snowflake, définissez explicitement le mode d’actualisation de toutes les tables dynamiques.

Pour vérifier le mode d’actualisation de vos tables dynamiques, consultez Actualiser le mode.

FULL

Impose une actualisation complète de la table dynamique, même si celle-ci peut être actualisée de manière incrémentielle.

INCREMENTAL

Permet une actualisation incrémentielle de la table dynamique. Si la requête qui sous-tend la table dynamique ne peut pas effectuer une actualisation incrémentielle, la création de la table dynamique échoue et affiche un message d’erreur.

Pour plus d’informations sur la manière dont les opérateurs affectent l’actualisation incrémentielle, voir Optimiser les requêtes pour l’actualisation incrémentielle.

Par défaut : AUTO

INITIALIZE

Spécifie le comportement de l’actualisation initiale de la table dynamique. Cette propriété ne peut pas être modifiée après la création de la table dynamique. Pour modifier la propriété, remplacez la table dynamique avec une commande CREATE OR REPLACE DYNAMIC TABLE.

ON_CREATE

Actualise la table dynamique de manière synchrone lors de sa création. Si cette actualisation échoue, la création de la table dynamique échoue et affiche un message d’erreur.

ON_SCHEDULE

Actualise la table dynamique lors de la prochaine actualisation planifiée.

La table dynamique est alimentée lors de l’exécution du processus de planification de l’actualisation. Aucune donnée n’est ajoutée lors de la création de la table dynamique. Si vous essayez d’interroger la table à l’aide de SELECT * FROM DYNAMIC TABLE, vous risquez d’obtenir l’erreur suivante, car la première actualisation planifiée n’a pas encore eu lieu.

Dynamic Table is not initialized. Please run a manual refresh or wait for a scheduled refresh before querying.

Par défaut : ON_CREATE

COMMENT 'string_literal'

Spécifie un commentaire pour la colonne.

(Notez que les commentaires peuvent être spécifiés au niveau de la colonne ou de la table. La syntaxe de chacun est légèrement différente).

MASKING POLICY = policy_name

Spécifie la politique de masquage à définir sur une colonne.

PROJECTION POLICY policy_name

Spécifie la politique de projection à définir sur une colonne.

Ce paramètre n’est pas pris en charge par la syntaxe de variante CREATE OR ALTER.

column_list

Si vous voulez modifier le nom d’une colonne ou ajouter un commentaire à une colonne dans la table dynamique, incluez une liste de colonnes qui spécifie les noms des colonnes et, le cas échéant, les commentaires sur les colonnes. Vous n’avez pas besoin de spécifier les types de données des colonnes.

Si l’une des colonnes de la table dynamique est basée sur des expressions (pas seulement des noms de colonnes simples, par exemple), vous devez fournir un nom de colonne pour chaque colonne de la table dynamique. Par exemple, les noms de colonnes sont obligatoires dans le cas suivant :

CREATE DYNAMIC TABLE my_dynamic_table (pre_tax_profit, taxes, after_tax_profit)
  TARGET_LAG = '20 minutes'
    WAREHOUSE = mywh
    AS
      SELECT revenue - cost, (revenue - cost) * tax_rate, (revenue - cost) * (1.0 - tax_rate)
      FROM staging_table;

Copy

Vous pouvez spécifier un commentaire facultatif pour chaque colonne. Par exemple :

CREATE DYNAMIC TABLE my_dynamic_table (pre_tax_profit COMMENT 'revenue minus cost',
                taxes COMMENT 'assumes taxes are a fixed percentage of profit',
                after_tax_profit)
  TARGET_LAG = '20 minutes'
    WAREHOUSE = mywh
    AS
      SELECT revenue - cost, (revenue - cost) * tax_rate, (revenue - cost) * (1.0 - tax_rate)
      FROM staging_table;

Copy

WITH CONTACT ( purpose = contact [ , purpose = contact ...] )

Associez le nouvel objet à un ou plusieurs contacts.

Spécifiez la clause WITH CONTACT après toutes les autres clauses à l’exception de la clause AS (si cette clause est prise en charge par cette commande).

ICEBERG_VERSION = integer

Fonction de prévisualisation — En accès libre

Disponible pour tous les comptes.

Spécifie la version de la spécification Apache Iceberg™ à laquelle la table est conforme.

Prudence

Avant d’utiliser d’autres moteurs pour mettre à niveau une version de format de tables Iceberg dans les propriétés de table vers la v3, assurez-vous que la table n’est pas utilisée par des moteurs ou des applications qui ne prennent pas encore en charge la v3. La rétrogradation des versions de format n’est pas prise en charge dans la spécification Apache Iceberg. Par conséquent, tous les lecteurs et rédacteurs doivent prendre en charge la v3. La version par défaut des tables Iceberg dans Snowflake est la v2, qui peut être configurée en v3 si nécessaire. L’utilisation de Snowflake pour effectuer des mises à niveau de version sur place n’est pas prise en charge pour le moment.

Si vous ne définissez pas ce paramètre, la table Iceberg utilise par défaut la version Iceberg du schéma, de la base de données ou du compte. Le schéma est prioritaire sur la base de données, et la base de données est prioritaire sur le compte.

• 2 : La table est conforme à la version 2 d’Iceberg.

• 3 : La table est conforme à la version 3 d’Iceberg.

Par défaut : 2

Pour plus d’informations sur ce paramètre, voir ICEBERG_VERSION.

CLUSTER BY ( expr [ , expr , ... ] )

Spécifie une ou plusieurs colonnes ou expressions de colonne de la table dynamique comme clés de clustering. Avant de spécifier une clé de clustering pour une table dynamique, vous devez comprendre ce que sont les micro-partitions. Pour plus d’informations, voir Fonctionnement des structures de table dans Snowflake.

Notez les points suivants lors de l’utilisation de clés de clustering avec des tables dynamiques :

• Les définitions des colonnes sont obligatoires et doivent être explicitement spécifiées dans l’instruction.

• Par défaut, le clustering automatique n’est pas suspendu pour la nouvelle table dynamique, même si le clustering automatique est suspendu pour la table source.

• Les clés de clustering ne sont pas prévues ni recommandées pour toutes les tables ; elles sont généralement intéressantes pour les tables de très grande taille (par exemple, de plusieurs téraoctets).

• La spécification de CLUSTER BY n’entraîne pas la mise en cluster des données au moment de la création ; en revanche, CLUSTER BY s’appuie sur le clustering automatique pour remettre en cluster les données au fil du temps.

Pour plus d’informations, voir Clés de clustering et tables en cluster.

Par défaut : aucune valeur (aucune clé de clustering n’est définie pour la table)

DATA_RETENTION_TIME_IN_DAYS = integer

Spécifie la période de conservation de la table dynamique pour que les actions Time Travel (SELECT, CLONE) puissent être effectuées sur les données historiques de la table dynamique. Time Travel se comporte de la même manière pour les tables dynamiques que pour les tables traditionnelles. Pour plus d’informations, voir Compréhension et utilisation de la fonction Time Travel.

Pour une description détaillée de ce paramètre de niveau objet, ainsi que plus d’informations sur les paramètres d’objet, voir Paramètres.

Valeurs :

• Édition Standard : 0 ou 1

• Édition Enterprise :

  • 0 à 90 pour les tables permanentes

  • 0 ou 1 pour les tables temporaires et transitoires

Par défaut :

• Édition Standard : 1

• Édition Enterprise (ou supérieure) : 1 (sauf si une valeur par défaut différente a été spécifiée au niveau du compte, du schéma ou de la base de données)

Note

Une valeur de 0 désactive effectivement Time Travel pour la table.

MAX_DATA_EXTENSION_TIME_IN_DAYS = integer

Un paramètre d’objet qui définit le nombre maximum de jours pendant lesquels Snowflake peut prolonger la période de conservation pour éviter que les flux de la table dynamique ne deviennent obsolètes.

Pour une description détaillée de ce paramètre, voir MAX_DATA_EXTENSION_TIME_IN_DAYS.

COMMENT = 'string_literal'

Spécifie un commentaire pour la table dynamique.

(Notez que les commentaires peuvent être spécifiés au niveau de la colonne ou de la table. La syntaxe de chacun est légèrement différente).

Par défaut : aucune valeur.

COPY GRANTS

Spécifie de conserver les privilèges d’accès de la table d’origine lorsqu’une nouvelle table dynamique est créée à l’aide de l’une des variables CREATE DYNAMIC TABLE suivantes :

• CREATE OR REPLACE DYNAMIC TABLE

• CREATE OR REPLACE DYNAMIC ICEBERG TABLE

• CREATE OR REPLACE DYNAMIC TABLE … CLONE

Ce paramètre copie tous les privilèges excepté OWNERSHIP de la table dynamique existante vers la nouvelle table dynamique. La nouvelle table dynamique n’hérite pas des attributions futures définies pour le type d’objet dans le schéma. Par défaut, le rôle qui exécute l’instruction CREATE DYNAMICTABLE possède la nouvelle table dynamique.

Si ce paramètre n’est pas inclus dans l’instruction CREATE DYNAMIC TABLE, la nouvelle table n’hérite pas des privilèges d’accès explicites accordés sur la table dynamique d’origine, mais des attributions futures définies pour le type d’objet dans le schéma.

Si l’instruction remplace une table existante du même nom, les autorisations sont copiées à partir de la table à remplacer. S’il n’existe aucune table de ce nom, les autorisations sont copiées.

Par exemple, l’instruction suivante crée une table dynamique dt1 clonée depuis dt0 avec toutes les autorisations copiées depuis dt0. La première fois que vous exécutez la commande, dt1 copie toutes les autorisations depuis dt0. Si vous exécutez à nouveau cette commande, dt1 copiera toutes les autorisations depuis dt1 et non dt0.

CREATE OR REPLACE DYNAMIC TABLE dt1 CLONE dt0
  COPY GRANTS;

Copy

Remarques :

• Avec le partage des données :

  • Si la table dynamique existante a été partagée avec un autre compte, la table dynamique de remplacement est également partagée.

  • Si la table dynamique existante a été partagée avec votre compte en tant que consommateur de données et que l’accès a été accordé à d’autres rôles dans le compte (en utilisant GRANT IMPORTED PRIVILEGES sur la base de données mère), l’accès est également accordé à la table dynamique de remplacement.

• La sortie SHOW GRANTS pour la table dynamique de remplacement liste le concessionnaire des privilèges copiés comme le rôle qui a exécuté l’instruction CREATE TABLE avec l’horodatage courant lorsque l’instruction a été exécutée.

• L’opération de copie des accords s’effectue atomiquement dans la commande CREATE DYNAMIC TABLE (c’est-à-dire dans la même transaction).

Important

Le paramètre COPY GRANTS peut être placé n’importe où dans une commande CREATE [ OR REPLACE ] DYNAMIC TABLE, sauf après la définition de la requête.

Par exemple, la création de la table dynamique suivante échouera :

CREATE OR REPLACE DYNAMIC TABLE my_dynamic_table
  TARGET_LAG = DOWNSTREAM
  WAREHOUSE = mywh
  AS
    SELECT * FROM staging_table
    COPY GRANTS;

Copy

ROW ACCESS POLICY policy_name ON ( col_name [ , col_name ... ] )

Spécifie la politique d’accès aux lignes à définir sur une table dynamique.

TAG ( tag_name = 'tag_value' [ , tag_name = 'tag_value' , ... ] )

Spécifie le nom de la balise et la valeur de la chaîne de la balise.

La valeur de la balise est toujours une chaîne de caractères et le nombre maximum de caractères pour la valeur de la balise est 256.

Pour plus d’informations sur la spécification des balises dans une instruction, voir Quotas de balises.

AGGREGATION POLICY policy_name [ ENTITY KEY ( col_name [ , col_name ... ] ) ]

Spécifie une politique d’agrégation à définir sur une table dynamique. Vous pouvez appliquer une ou plusieurs politiques d’agrégation à une table.

Utilisez le paramètre facultatif ENTITY KEY pour définir les colonnes qui identifient de manière unique une entité dans la table dynamique. Pour plus d’informations, voir Mise en œuvre de la protection de la confidentialité au niveau de l’entité à l’aide de politiques d’agrégation. Vous pouvez spécifier une ou plusieurs clés d’entité pour une politique d’agrégation.

Ce paramètre n’est pas pris en charge par la syntaxe de variante CREATE OR ALTER.

REQUIRE USER

Si spécifié, le tableau dynamique ne peut être exécuté que si un utilisateur est spécifié. La table dynamique n’est pas en mesure de s’actualiser sauf si un utilisateur est défini dans une actualisation manuelle avec le paramètre COPY SESSION spécifié.

Si cette option est activée, la table dynamique doit être créée avec le paramètre ON_SCHEDULE pour INITIALIZE.

IMMUTABLE WHERE

Spécifie une condition qui définit la partie immuable de la table dynamique. Pour plus d’informations, voir Compréhension des contraintes d’immuabilité.

BACKFILL FROM <name>

Spécifie la table à partir de laquelle les données sont remplies.

Seules les données définies par la contrainte d’immuabilité IMMUTABLE WHERE peuvent être remplies, car les données de remplissage doivent rester inchangées, même si elles diffèrent de la source en amont.

Pour plus d’informations, voir Exemples de remplissage rétroactif.

EXECUTE AS USER user_name

Actualise la table dynamique en tant qu’utilisateur spécifié.

Pour spécifier EXECUTE AS USER, vous devez utiliser un rôle qui s’est vu accorder le privilège IMPERSONATE sur l’utilisateur user_name. Pour accorder ce privilège, exécutez la commande GRANT <privilèges> … TO ROLE.

USE SECONDARY ROLES { ALL | NONE | <role> [ , ... ] }

Spécifie les rôles secondaires à utiliser sur la table dynamique. Peut être utilisé pour remplacer les rôles secondaires par défaut qui sont autrement utilisés dans l’exécution.

Ne peut être utilisé qu’avec l’option EXECUTE AS USER.

Pour plus d’informations, voir Actualiser des tables dynamiques avec des privilèges utilisateur et des rôles secondaires spécifiques.

ROW_TIMESTAMP = { TRUE | FALSE }

Spécifie s’il faut activer les horodatages des lignes sur la table. Vous devez utiliser un rôle disposant du privilège OWNERSHIP.

Pour plus d’informations, voir Utiliser des horodatages de lignes pour mesurer la latence dans vos pipelines.

Exigences en matière de contrôle d’accès¶

Un rôle utilisé pour exécuter cette opération doit au minimum disposer des privilèges suivants :

Pour effectuer une opération sur un objet dans un schéma, il est nécessaire de disposer d’au moins un privilège sur la base de données parente et d’au moins un privilège sur le schéma parent.

Pour obtenir des instructions sur la création d’un rôle personnalisé avec un ensemble spécifique de privilèges, voir Création de rôles personnalisés.

Pour des informations générales sur les rôles et les privilèges accordés pour effectuer des actions SQL sur des objets sécurisables, voir Aperçu du contrôle d’accès.

Notes sur l’utilisation¶

• Lorsque vous exécutez la commande CREATE DYNAMIC TABLE, le rôle en cours d’utilisation devient propriétaire de la table dynamique. Ce rôle est utilisé pour effectuer des actualisations de la table dynamique en arrière-plan.

• Vous ne pouvez pas modifier le schéma après avoir créé une table dynamique.

• Les tables dynamiques sont mises à jour lorsque les objets de la base de données sous-jacente changent. Le suivi des modifications doit être activé pour tous les objets sous-jacents utilisés par une table dynamique. Voir Activer le suivi des modifications.

• Si vous souhaitez remplacer une table dynamique existant et que vous avez besoin de voir sa définition actuelle, appelez la fonction GET_DDL.

• L’utilisation de ORDER BY dans la définition d’une table dynamique peut produire des résultats triés dans un ordre imprévu. Vous pouvez utiliser ORDER BY lorsque vous interrogez votre table dynamique afin de vous assurer que les lignes sélectionnées sont renvoyées dans un ordre spécifique.

• Snowflake ne prend pas en charge l’utilisation de ORDER BY pour créer une vue qui effectue une sélection à partir d’une table dynamique.

• Pour influencer l’ordre dans lequel les lignes sont stockées dans une table dynamique, envisagez d’activer le clustering.

• Certaines expressions, clauses et fonctions ne sont actuellement pas prises en charge dans les tables dynamiques. Pour une liste complète, voir Limites des tables dynamiques.

• Utiliser OR REPLACE équivaut à utiliser DROP DYNAMIC TABLE sur la table dynamique existante, puis à créer une nouvelle table dynamique portant le même nom. Cependant, Snowflake ne supprime pas l’ancienne table dynamique tant qu’il n’a pas créé la nouvelle table dynamique et effectué l’actualisation initiale si INITIALIZE = ON_CREATE est spécifié. Au lieu de cela, la nouvelle table dynamique est créée en tant que table masquée, l’actualisation est exécutée, puis Snowflake remplace la table dynamique existante par la nouvelle table.

• Les clients doivent s’assurer qu’aucune donnée personnelle (autre que pour un objet utilisateur), donnée sensible, donnée à exportation contrôlée ou autre donnée réglementée n’est saisie comme métadonnée lors de l’utilisation du service Snowflake. Pour plus d’informations, voir Champs de métadonnées dans Snowflake.

• Les clauses OR REPLACE et IF NOT EXISTS s’excluent mutuellement. Elles ne peuvent pas être utilisées dans la même instruction.

• Les instructions CREATE OR REPLACE <objet> sont atomiques. En d’autres termes, lorsqu’un objet est remplacé, l’ancien objet est supprimé et le nouvel objet est créé dans une seule transaction.

Notes sur l’utilisation de CREATE OR ALTER DYNAMICTABLE¶

• Toutes les limitations de la commande ALTER DYNAMIC TABLE s’appliquent.

CREATE OR ALTER execution failed. Partial updates may have been applied.

Notes sur l’utilisation de IMMUTABLE WHERE¶

• Vous ne pouvez définir qu’un seul prédicat IMMUTABLE WHERE par table dynamique. La définition d’un autre prédicat remplace le prédicat existant.

• Les contraintes IMMUTABLE WHERE ne peuvent pas contenir :

  • Sous-requêtes

  • Fonctions non déterministes, à l’exception des fonctions d’horodatage telles que CURRENT_TIMESTAMP() ou CURRENT_DATE().

  • Fonctions définies par l’utilisateur et fonctions externes

  • Colonnes de métadonnées (celles commençant par METADATA$)

  • Colonnes qui résultent d’agrégats, de fonctions de fenêtre ou de fonctions non déterministes

• Lorsque vous utilisez des fonctions d’horodatage, la région immuable ne peut pas se réduire au fil du temps. Par exemple, TIMESTAMP_COL < CURRENT_TIMESTAMP() is allowed, but TIMESTAMP_COL > CURRENT_TIMESTAMP() ne l’est pas.

• Les colonnes référencées dans la condition IMMUTABLE WHERE doivent être constituées de colonnes de la table dynamique, et non de colonnes de la table de base.

• Les limitations suivantes s’appliquent lorsque vous utilisez des contraintes d’immuabilité et des données réintégrées :

  • Actuellement, seules les tables standards et dynamiques peuvent être utilisées pour le remplissage.

  • Vous ne pouvez pas spécifier de politiques ni de balises dans la nouvelle table dynamique, car elles sont copiées à partir de la table de remplissage.

  • Les clés de clustering de la nouvelle table dynamique et de la table de remplissage doivent être identiques.

Exemples¶

Créez une table dynamique nommée my_dynamic_table :

CREATE OR REPLACE DYNAMIC TABLE my_dynamic_table
  TARGET_LAG = '20 minutes'
  WAREHOUSE = mywh
  AS
    SELECT product_id, product_name FROM staging_table;

Dans l’exemple ci-dessus :

• La table dynamique matérialise les résultats d’une requête sur les colonnes product_id et product_name de la table staging_table.

• Le temps de latence cible est de 20 minutes, ce qui signifie que les données de la table dynamique ne devraient idéalement pas être antérieures de plus de 20 minutes à celles de la staging_table.

• Le processus d’actualisation automatisé utilise les ressources informatiques de l’entrepôt mywh pour actualiser les données de la table dynamique.

Créer une table Iceberg dynamique nommée my_dynamic_table qui lit à partir de my_iceberg_table :

CREATE DYNAMIC ICEBERG TABLE my_dynamic_table (date TIMESTAMP_NTZ, id NUMBER, content STRING)
  TARGET_LAG = '20 minutes'
  WAREHOUSE = mywh
  EXTERNAL_VOLUME = 'my_external_volume'
  CATALOG = 'SNOWFLAKE'
  BASE_LOCATION = 'my_iceberg_table'
  AS
    SELECT product_id, product_name FROM staging_table;

Créez une table dynamique avec une clé de clustering à plusieurs colonnes :

CREATE DYNAMIC TABLE my_dynamic_table (date TIMESTAMP_NTZ, id NUMBER, content VARIANT)
  TARGET_LAG = '20 minutes'
  WAREHOUSE = mywh
  CLUSTER BY (date, id)
  AS
    SELECT product_id, product_name FROM staging_table;

Cloner une table dynamique telle qu’elle existait exactement à la date et à l’heure de l’horodatage spécifié :

CREATE DYNAMIC TABLE my_cloned_dynamic_table CLONE my_dynamic_table AT (TIMESTAMP => TO_TIMESTAMP_TZ('04/05/2013 01:02:03', 'mm/dd/yyyy hh24:mi:ss'));

Configurer une table dynamique pour demander à un utilisateur des actualisations et actualiser la table dynamique :

CREATE DYNAMIC TABLE my_dynamic_table
  TARGET_LAG = 'DOWNSTREAM'
  WAREHOUSE = mywh
  INITIALIZE = on_schedule
  REQUIRE USER
  AS
    SELECT product_id, product_name FROM staging_table;

ALTER DYNAMIC TABLE my_dynamic_table REFRESH COPY SESSION;

Créer une table dynamique avec une contrainte d’immuabilité :

CREATE DYNAMIC TABLE my_dynamic_table
  TARGET_LAG = '1 hour'
  WAREHOUSE = my_warehouse
  IMMUTABLE WHERE (ts < CURRENT_TIMESTAMP() - INTERVAL '1 day')
AS
  SELECT * FROM source_table;

Créer une table dynamique avec la commande CREATE OR ALTER DYNAMIC TABLE :

CREATE OR ALTER DYNAMIC TABLE my_dynamic_table
  TARGET_LAG = DOWNSTREAM
  WAREHOUSE = mywh
  AS
    SELECT a, b FROM t;

Modifier une table dynamique pour définir le paramètre DATA_RETENTION_TIME_IN_DAYS et ajouter une clé de clustering :

CREATE OR ALTER DYNAMIC TABLE my_dynamic_table
 TARGET_LAG = DOWNSTREAM
 WAREHOUSE = mywh
 DATA_RETENTION_TIME_IN_DAYS = 2
 CLUSTER BY (a)
 AS
   SELECT a, b FROM t;

Modifier la latence cible et l’entrepôt :

CREATE OR ALTER DYNAMIC TABLE my_dynamic_table
 TARGET_LAG = '5 minutes'
 WAREHOUSE = my_other_wh
 DATA_RETENTION_TIME_IN_DAYS = 2
 CLUSTER BY (a)
 AS
   SELECT a, b FROM t;

Annulez la définition du paramètre DATA_RETENTION_TIME_IN_DAYS. L’absence d’un paramètre dans l’instruction CREATE OR ALTER DYNAMIC TABLE modifiée entraîne sa désactivation. Dans ce cas, la désactivation du paramètre DATA_RETENTION_TIME_IN_DAYS de la table dynamique le rétablit à la valeur par défaut de 1 :

CREATE OR ALTER DYNAMIC TABLE my_dynamic_table
 TARGET_LAG = '5 minutes'
 WAREHOUSE = my_other_wh
 CLUSTER BY (a)
 AS
   SELECT a, b FROM t;

Écrire une table Iceberg v3 gérée par Snowflake

L’exemple suivant écrit une table Iceberg v3 gérée par Snowflake comme sortie d’une table dynamique :

CREATE DYNAMIC ICEBERG TABLE my_dynamic_iceberg_v3_table (
    num_orders NUMBER(10,0),
    order_day
  )
  TARGET_LAG = '20 minutes'
  WAREHOUSE = my_warehouse
  EXTERNAL_VOLUME = 'my_external_volume'
  CATALOG = 'SNOWFLAKE'
  BASE_LOCATION = 'my_dynamic_iceberg_v3_table'
  ICEBERG_VERSION = 3
  AS
    SELECT
        COUNT(DISTINCT order_id)
        DATE_TRUNC('DAY', order_timestamp_ns) AS order_day
      FROM staging_v3_iceberg_table;