Guide de traduction SQL Teradata

Ce document décrit les similitudes et les différences de syntaxe SQL entre Teradata et BigQuery pour vous aider à planifier votre migration. Utilisez la traduction SQL par lot pour migrer vos scripts SQL de façon groupée, ou la traduction SQL interactive pour traduire des requêtes ad hoc.

Types de données

Cette section présente les équivalences entre les types de données Teradata et BigQuery.

Teradata	BigQuery	Remarques
`INTEGER`	`INT64`
`SMALLINT`	`INT64`
`BYTEINT`	`INT64`
`BIGINT`	`INT64`
`DECIMAL`	`NUMERIC, DECIMAL` `BIGNUMERIC, BIGDECIMAL`	Utilisez la valeur `NUMERIC` (alias `DECIMAL`) de BigQuery lorsque l'échelle (chiffres après la virgule) est inférieure ou égale à 9. Utilisez la valeur `BIGNUMERIC` de BigQuery (alias `BIGDECIMAL`) lorsque l'échelle est supérieure à 9. Utilisez les types de données décimales paramétrés de BigQuery si vous devez appliquer des limites de chiffres ou d'échelles personnalisées (contraintes). Teradata vous permet d'insérer des valeurs de précision plus élevée en arrondissant la valeur stockée, mais conserve une haute précision des calculs. Cela peut entraîner un comportement inattendu en ce qui concerne les arrondis, par rapport à la norme ANSI.
`FLOAT`	`FLOAT64`
`NUMERIC`	`NUMERIC, DECIMAL` `BIGNUMERIC, BIGDECIMAL`	Utilisez la valeur `NUMERIC` (alias `DECIMAL`) de BigQuery lorsque l'échelle (chiffres après la virgule) est inférieure ou égale à 9. Utilisez la valeur `BIGNUMERIC` de BigQuery (alias `BIGDECIMAL`) lorsque l'échelle est supérieure à 9. Utilisez les types de données décimales paramétrés de BigQuery si vous devez appliquer des limites de chiffres ou d'échelles personnalisées (contraintes). Teradata vous permet d'insérer des valeurs de précision plus élevée en arrondissant la valeur stockée, mais conserve une haute précision des calculs. Cela peut entraîner un comportement inattendu en ce qui concerne les arrondis, par rapport à la norme ANSI.
`NUMBER`	`NUMERIC, DECIMAL` `BIGNUMERIC, BIGDECIMAL`	Utilisez la valeur `NUMERIC` (alias `DECIMAL`) de BigQuery lorsque l'échelle (chiffres après la virgule) est inférieure ou égale à 9. Utilisez la valeur `BIGNUMERIC` de BigQuery (alias `BIGDECIMAL`) lorsque l'échelle est supérieure à 9. Utilisez les types de données décimales paramétrés de BigQuery si vous devez appliquer des limites de chiffres ou d'échelles personnalisées (contraintes). Teradata vous permet d'insérer des valeurs de précision plus élevée en arrondissant la valeur stockée, mais conserve une haute précision des calculs. Cela peut entraîner un comportement inattendu en ce qui concerne les arrondis, par rapport à la norme ANSI.
`REAL`	`FLOAT64`
`CHAR/CHARACTER`	`STRING`	Utilisez le type de données `STRING` paramétré si vous devez appliquer un nombre maximal de caractères.
`VARCHAR`	`STRING`	Utilisez le type de données `STRING` paramétré si vous devez appliquer un nombre maximal de caractères.
`CLOB`	`STRING`
`JSON`	`JSON`
`BLOB`	`BYTES`
`BYTE`	`BYTES`
`VARBYTE`	`BYTES`
`DATE`	`DATE`	BigQuery n'est pas compatible avec une mise en forme personnalisée semblable à celle qu'accepte Teradata avec DataForm dans SDF.
`TIME`	`TIME`
`TIME WITH TIME ZONE`	`TIME`	Teradata stocke le type de données `TIME` au format UTC et vous permet de transmettre un décalage par rapport à l'heure UTC à l'aide de la syntaxe `WITH TIME ZONE`.Le type de données `TIME` de BigQuery représente une heure indépendante de toute date ou de tout fuseau horaire.
`TIMESTAMP`	`TIMESTAMP`	Les types de données `TIMESTAMP` de Teradata et BigQuery ont une précision de l'ordre de la microseconde (mais Teradata accepte les secondes intercalaires, contrairement à BigQuery). Les types de données de Teradata et BigQuery sont généralement associés à un fuseau horaire UTC (en savoir plus).
`TIMESTAMP WITH TIME ZONE`	`TIMESTAMP`	Le type de données `TIMESTAMP` de Teradata peut être défini sur un fuseau horaire différent à l'échelle du système, par utilisateur ou par colonne (à l'aide de `WITH TIME ZONE`). Le type de données `TIMESTAMP` de BigQuery suppose que la valeur est UTC si vous ne spécifiez pas explicitement de fuseau horaire. Veillez à exporter correctement les informations de fuseau horaire (ne concaténez pas les valeurs `DATE` et `TIME` sans informations de fuseau horaire) afin que BigQuery puisse les convertir lors de l'importation. Sinon, vous pouvez également convertir les informations de fuseau horaire au format UTC avant de les exporter. BigQuery dispose du type de données `DATETIME` pour une abstraction entre le temps civil, qui n'affiche pas de fuseau horaire lors de la sortie, et `TIMESTAMP`, qui correspond à un moment précis qui affiche toujours le fuseau horaire UTC.
`ARRAY`	`ARRAY`
`MULTI-DIMENSIONAL ARRAY`	`ARRAY`	Dans BigQuery, utilisez un tableau de structures, chaque structure contenant un champ de type `ARRAY` (pour en savoir plus, consultez la documentation BigQuery).
`INTERVAL HOUR`	`INT64`
`INTERVAL MINUTE`	`INT64`
`INTERVAL SECOND`	`INT64`
`INTERVAL DAY`	`INT64`
`INTERVAL MONTH`	`INT64`
`INTERVAL YEAR`	`INT64`
`PERIOD(DATE)`	`DATE`, `DATE`	`PERIOD(DATE)` doit être converti en deux colonnes `DATE` contenant la date de début et la date de fin, de sorte qu'elles puissent être utilisées avec des fonctions de fenêtrage.
`PERIOD(TIMESTAMP WITH TIME ZONE)`	`TIMESTAMP`, `TIMESTAMP`
`PERIOD(TIMESTAMP)`	`TIMESTAMP`, `TIMESTAMP`
`PERIOD(TIME)`	`TIME`, `TIME`
`PERIOD(TIME WITH TIME ZONE)`	`TIME`, `TIME`
`UDT`	`STRING`
`XML`	`STRING`
`TD_ANYTYPE`	`STRING`

Pour plus d'informations sur le casting des types de données, consultez la section suivante.

Mise en forme des types de données Teradata

Le langage SQL Teradata utilise un ensemble de formats par défaut pour afficher les expressions et les données des colonnes, ainsi que pour les conversions entre les types de données. Par exemple, un type de données PERIOD(DATE) en mode INTEGERDATE a le format par défaut YY/MM/DD. Nous vous recommandons d'utiliser le mode ANSIDATE dans la mesure du possible afin de garantir la conformité avec ANSI SQL, et d'en profiter pour nettoyer les anciens formats.

Teradata permet l'application automatique de formats personnalisés à l'aide de la clause FORMAT, sans modifier le stockage sous-jacent, en tant qu'attribut de type de données lorsque vous créez une table à l'aide du LDD ou dans une expression dérivée. Par exemple, une spécification de FORMAT 9.99 arrondit toute valeur FLOAT à deux chiffres. Dans BigQuery, cette fonctionnalité doit être convertie à l'aide de la fonction ROUND().

Cette fonctionnalité nécessite la gestion de cas spéciaux complexes. Par exemple, lorsque la clause FORMAT est appliquée à une colonne NUMERIC, vous devez tenir compte de règles d'arrondi et de mise en forme spéciales. Une clause FORMAT peut être utilisée pour caster implicitement une valeur epoch INTEGER dans un format DATE. Ou une spécification de FORMAT X(6) sur une colonne VARCHAR tronque la valeur de la colonne. Vous devez donc la convertir en fonction SUBSTR(). Ce comportement n'est pas compatible avec ANSI SQL. Par conséquent, nous vous recommandons de ne pas migrer les formats de colonnes vers BigQuery.

Si les formats de colonnes sont absolument obligatoires, utilisez des vues ou des fonctions définies par l'utilisateur (UDF).

Pour en savoir plus sur les formats par défaut utilisés par le langage SQL Teradata pour chaque type de données, consultez la documentation sur la mise en forme par défaut de Teradata.

Mise en forme des types d'horodatage et de date

Le tableau suivant récapitule les différences entre les éléments de mise en forme d'horodatages et de dates entre le langage SQL de Teradata et GoogleSQL.

Format Teradata	Description de l'élément Teradata	BigQuery
`CURRENT_TIMESTAMP CURRENT_TIME`	Les informations `TIME` et `TIMESTAMP` dans Teradata peuvent avoir des informations de fuseau horaire différentes, définies à l'aide de `WITH TIME ZONE`.	Si possible, utilisez `CURRENT_TIMESTAMP()`, qui est au format ISO. Toutefois, le format de sortie affiche toujours le fuseau horaire UTC. (En interne, BigQuery n'a pas de fuseau horaire.) Notez les détails suivants concernant les différences du format ISO. Le format de `DATETIME` repose sur des conventions de canal de sortie. Dans l'outil de ligne de commande BigQuery et la console BigQuery, il est mis en forme à l'aide d'un séparateur `T` conformément à la norme RFC 3339. Toutefois, dans Python et Java JDBC, un espace est utilisé comme séparateur. Si vous souhaitez utiliser un format explicite, utilisez `FORMAT_DATETIME()`, qui permet de caster une chaîne de manière explicite. Par exemple, l'expression suivante renvoie toujours un espace comme séparateur : `CAST(CURRENT_DATETIME() AS STRING)` Teradata accepte un mot clé `DEFAULT` dans les colonnes `TIME` pour définir l'heure actuelle (horodatage). Cela n'est pas utilisé dans BigQuery.
`CURRENT_DATE`	Les dates sont stockées dans Teradata en tant que valeurs `INT64` à l'aide de la formule suivante : `(YEAR - 1900) * 10000 + (MONTH * 100) + DAY` Les dates peuvent être mises en forme sous forme d'entiers.	BigQuery possède un format `DATE` distinct qui renvoie toujours une date au format ISO 8601. `DATE_FROM_UNIX_DATE` ne peut pas être utilisé, car il repose sur le nombre de secondes écoulées depuis le 1er janvier 1970. Teradata accepte un mot clé `DEFAULT` dans les colonnes `DATE` pour définir la date actuelle. Cela n'est pas utilisé dans BigQuery.
`CURRENT_DATE-3`	Les valeurs de date sont représentées sous forme d'entiers. Teradata accepte les opérateurs arithmétiques pour les types de date.	Pour les types de date, utilisez `DATE_ADD()` ou `DATE_SUB()`. BigQuery utilise des opérateurs arithmétiques pour les types de données suivants : `INT64`, `NUMERIC` et `FLOAT64`.
`SYS_CALENDAR.CALENDAR`	Teradata fournit une vue pour les opérations d'agenda au-delà des opérations entières.	Non utilisé dans BigQuery.
`SET SESSION DATEFORM=ANSIDATE`	Définissez le format de date système ou de session sur ANSI (ISO 8601).	BigQuery utilise toujours la norme ISO 8601. Par conséquent, veillez à convertir les dates et heures Teradata.

Syntaxe des requêtes

Cette section traite des différences de syntaxe des requêtes entre Teradata et BigQuery.

Instruction `SELECT`

La plupart des instructions SELECT Teradata sont compatibles avec BigQuery. Le tableau suivant contient une liste de différences mineures.

Teradata		BigQuery
`SEL`		Conversion en `SELECT`. BigQuery n'utilise pas l'abréviation `SEL`.
`SELECT (subquery) AS flag, CASE WHEN flag = 1 THEN ...`		Dans BigQuery, les colonnes ne peuvent pas faire référence à la sortie d'autres colonnes définies au sein de la même liste de sélection. Il vaut mieux déplacer une sous-requête dans une clause `WITH`. `WITH flags AS ( subquery ), SELECT CASE WHEN flags.flag = 1 THEN ...`
`SELECT * FROM table WHERE A LIKE ANY ('string1', 'string2')`		BigQuery n'utilise pas le prédicat logique `ANY`. La même fonctionnalité peut être obtenue en utilisant plusieurs opérateurs `OR` : `SELECT * FROM table WHERE col LIKE 'string1' OR col LIKE 'string2'` Dans ce cas, la comparaison de chaînes diffère également. Consultez la section Opérateurs de comparaison.
`SELECT TOP 10 * FROM table`		BigQuery utilise `LIMIT` à la fin d'une requête au lieu de `TOP n` après le mot clé `SELECT`.

Opérateurs de comparaison

Le tableau suivant présente les opérateurs de comparaison qui sont spécifiques à Teradata et doivent être convertis en opérateurs compatibles avec ANSI SQL:2011 utilisés dans BigQuery.

Pour en savoir plus sur les opérateurs dans BigQuery, consultez la section Opérateurs de la documentation BigQuery.

Teradata	BigQuery	Remarques
`exp EQ exp2` `exp IN (exp2, exp3)`	`exp = exp2` `exp IN (exp2, exp3)` Pour conserver une sémantique autre que ANSI pour `NOT CASESPECIFIC`, vous pouvez utiliser `RTRIM(UPPER(exp)) = RTRIM(UPPER(exp2))`	En cas de comparaison de chaînes pour en vérifier l'égalité, Teradata peut ignorer les espaces blancs de fin, tandis que BigQuery considère qu'ils font partie de la chaîne. Par exemple, `'xyz'=' xyz'` est `TRUE` dans Teradata, mais `FALSE` dans BigQuery. Teradata fournit également un attribut de colonne `NOT CASESPECIFIC` qui indique à Teradata d'ignorer la casse lors de la comparaison de deux chaînes. BigQuery prend toujours en compte la casse lors de la comparaison de chaînes. Par exemple, `'xYz' = 'xyz'` est `TRUE` dans Teradata, mais `FALSE` dans BigQuery.
`exp LE exp2`	`exp <= exp2`
`exp LT exp2`	`exp < exp2`
`exp NE exp2`	`exp <> exp2 exp != exp2`
`exp GE exp2`	`exp >= exp2`
`exp GT exp2`	`exp > exp2`

`JOIN` conditions

BigQuery et Teradata acceptent les mêmes conditions JOIN, ON et USING. Le tableau suivant contient une liste de différences mineures.

Teradata	BigQuery	Remarques
`FROM A LEFT OUTER JOIN B ON A.date > B.start_date AND A.date < B.end_date`	`FROM A LEFT OUTER JOIN (SELECT d FROM B JOIN UNNEST(GENERATE_DATE_ARRAY(B.start_date, B.end_date)) d) B ON A.date = B.date`	BigQuery accepte les clauses `JOIN` d'inégalité pour toutes les jointures internes ou si au moins une condition d'égalité est spécifiée (=). En revanche, il n'accepte pas une seule condition d'inégalité (= et <) dans une jointure `OUTER JOIN`. Ce type de construction est parfois utilisé pour interroger des plages de dates ou d'entiers. BigQuery empêche les utilisateurs de créer par inadvertance des jointures croisées de grande taille.
`FROM A, B ON A.id = B.id`	`FROM A JOIN B ON A.id = B.id`	L'utilisation d'une virgule entre les tables dans Teradata équivaut à une jointure `INNER JOIN`, tandis que dans BigQuery, elle équivaut à une jointure `CROSS JOIN` (produit cartésien). Étant donné que la virgule dans l'ancien SQL de BigQuery est traitée comme un opérateur `UNION`, nous vous recommandons de rendre l'opération explicite pour éviter toute confusion.
`FROM A JOIN B ON (COALESCE(A.id , 0) = COALESCE(B.id, 0))`	`FROM A JOIN B ON (COALESCE(A.id , 0) = COALESCE(B.id, 0))`	Aucune différence pour les fonctions scalaires (constantes).
`FROM A JOIN B ON A.id = (SELECT MAX(B.id) FROM B)`	`FROM A JOIN (SELECT MAX(B.id) FROM B) B1 ON A.id = B1.id`	BigQuery empêche les utilisateurs d'utiliser des sous-requêtes, des sous-requêtes corrélées ou des agrégations dans les prédicats de jointure. Cela permet à BigQuery d'exécuter les requêtes en parallèle.

Casting et conversion des types de données

BigQuery propose des types de données moins nombreux, mais plus larges que Teradata, ce qui fait qu'il doit assurer un casting plus strict.

Teradata	BigQuery	Remarques
`exp EQ exp2` `exp IN (exp2, exp3)`	`exp = exp2` `exp IN (exp2, exp3)` Pour conserver une sémantique autre que ANSI pour `NOT CASESPECIFIC`, vous pouvez utiliser `RTRIM(UPPER(exp)) = RTRIM(UPPER(exp2))`	En cas de comparaison de chaînes pour en vérifier l'égalité, Teradata peut ignorer les espaces blancs de fin, tandis que BigQuery considère qu'ils font partie de la chaîne. Par exemple, `'xyz'=' xyz'` est `TRUE` dans Teradata, mais `FALSE` dans BigQuery. Teradata fournit également un attribut de colonne `NOT CASESPECIFIC` qui indique à Teradata d'ignorer la casse lors de la comparaison de deux chaînes. BigQuery prend toujours en compte la casse lors de la comparaison de chaînes. Par exemple, `'xYz' = 'xyz'` est `TRUE` dans Teradata, mais `FALSE` dans BigQuery.
`CAST(long_varchar_column AS CHAR(6))`	`LPAD(long_varchar_column, 6)`	Le casting d'une colonne de caractères dans Teradata est parfois utilisé comme un moyen non standard et non optimal de créer une sous-chaîne complétée.
`CAST(92617 AS TIME) 92617 (FORMAT '99:99:99')`	`PARSE_TIME("%k%M%S", CAST(92617 AS STRING))`	Teradata effectue beaucoup plus de conversions implicites de types de données et d'arrondis que BigQuery, qui est généralement plus strict et applique les normes ANSI. (Cet exemple renvoie 09:26:17)
`CAST(48.5 (FORMAT 'zz') AS FLOAT)`	`CAST(SUBSTR(CAST(48.5 AS STRING), 0, 2) AS FLOAT64)`	Les types de données numériques et à virgule flottante peuvent nécessiter des règles d'arrondi spéciales lorsqu'ils sont appliqués avec des formats tels que les devises. (Cet exemple renvoie 48)

Consultez également les sections sur les opérateurs de comparaison et les formats de colonnes. Les comparaisons et la mise en forme des colonnes peuvent se comporter de la même manière que des castings de types de données.

Clauses `QUALIFY`, `ROWS`

La clause QUALIFY de Teradata vous permet de filtrer les résultats pour des fenêtrages. Vous pouvez également utiliser une expression ROWS pour la même tâche. Elles fonctionnent de la même manière qu'une condition HAVING pour une clause GROUP, qui limite la sortie de ce que l'on appelle dans BigQuery des fonctions de fenêtrage.

Teradata BigQuery

SELECT col1, col2 FROM table QUALIFY ROW_NUMBER() OVER (PARTITION BY col1 ORDER BY col2) = 1; La clause QUALIFY de Teradata avec une fonction de fenêtrage telle que ROW_NUMBER(), SUM() ,COUNT() et OVER PARTITION BY est exprimée dans BigQuery en tant que clause WHERE sur une sous-requête contenant une valeur d'analyse.

Avec ROW_NUMBER() :

SELECT col1, col2 FROM ( SELECT col1, col2, ROW_NUMBER() OVER (PARTITION BY col1 ORDER BY col2) RN FROM table ) WHERE RN = 1;

Avec ARRAY_AGG, qui accepte des partitions plus grandes :

SELECT result.* FROM ( SELECT ARRAY_AGG(table ORDER BY table.col2 DESC LIMIT 1)[OFFSET(0)] FROM table GROUP BY col1 ) AS result;

SELECT col1, col2 FROM table AVG(col1) OVER (PARTITION BY col1 ORDER BY col2 ROWS BETWEEN 2 PRECEDING AND CURRENT ROW); SELECT col1, col2 FROM table AVG(col1) OVER (PARTITION BY col1 ORDER BY col2 RANGE BETWEEN 2 PRECEDING AND CURRENT ROW);

Dans BigQuery, RANGE et ROWS peuvent être utilisés dans la clause de fenêtrage. Cependant, les clauses de fenêtrage ne peuvent être utilisées qu'avec des fonctions de fenêtrage telles que AVG(), et non avec des fonctions de numérotation telles que ROW_NUMBER().

Teradata	BigQuery
`SELECT col1, col2 FROM table QUALIFY ROW_NUMBER() OVER (PARTITION BY col1 ORDER BY col2) = 1;`	La clause `QUALIFY` de Teradata avec une fonction de fenêtrage telle que `ROW_NUMBER()`, `SUM()` ,`COUNT()` et `OVER PARTITION BY` est exprimée dans BigQuery en tant que clause `WHERE` sur une sous-requête contenant une valeur d'analyse. Avec `ROW_NUMBER()` : `SELECT col1, col2 FROM ( SELECT col1, col2, ROW_NUMBER() OVER (PARTITION BY col1 ORDER BY col2) RN FROM table ) WHERE RN = 1;` Avec `ARRAY_AGG`, qui accepte des partitions plus grandes : `SELECT result.* FROM ( SELECT ARRAY_AGG(table ORDER BY table.col2 DESC LIMIT 1)[OFFSET(0)] FROM table GROUP BY col1 ) AS result;`
`SELECT col1, col2 FROM table AVG(col1) OVER (PARTITION BY col1 ORDER BY col2 ROWS BETWEEN 2 PRECEDING AND CURRENT ROW);`	`SELECT col1, col2 FROM table AVG(col1) OVER (PARTITION BY col1 ORDER BY col2 RANGE BETWEEN 2 PRECEDING AND CURRENT ROW);` Dans BigQuery, `RANGE` et `ROWS` peuvent être utilisés dans la clause de fenêtrage. Cependant, les clauses de fenêtrage ne peuvent être utilisées qu'avec des fonctions de fenêtrage telles que `AVG()`, et non avec des fonctions de numérotation telles que `ROW_NUMBER()`.

Mot clé `NORMALIZE`

Teradata fournit le mot clé NORMALIZE pour les clauses SELECT afin de fusionner les périodes ou les intervalles qui se chevauchent en une seule période ou un seul intervalle englobant toutes les valeurs de période individuelles.

BigQuery n'accepte pas le type PERIOD. Par conséquent, toute colonne de type PERIOD dans Teradata doit être insérée dans BigQuery sous la forme de deux champs DATE ou DATETIME distincts, qui correspondent au début et à la fin de la période.

Teradata BigQuery

SELECT NORMALIZE client_id, item_sid, BEGIN(period) AS min_date, END(period) AS max_date, FROM table; SELECT t.client_id, t.item_sid, t.min_date, MAX(t.dwh_valid_to) AS max_date FROM ( SELECT d1.client_id, d1.item_sid, d1.dwh_valid_to AS dwh_valid_to, MIN(d2.dwh_valid_from) AS min_date FROM table d1 LEFT JOIN table d2 ON d1.client_id = d2.client_id AND d1.item_sid = d2.item_sid AND d1.dwh_valid_to >= d2.dwh_valid_from AND d1.dwh_valid_from < = d2.dwh_valid_to GROUP BY d1.client_id, d1.item_sid, d1.dwh_valid_to ) t GROUP BY t.client_id, t.item_sid, t.min_date;

Teradata	BigQuery
`SELECT NORMALIZE client_id, item_sid, BEGIN(period) AS min_date, END(period) AS max_date, FROM table;`	SELECT t.client_id, t.item_sid, t.min_date, MAX(t.dwh_valid_to) AS max_date FROM ( SELECT d1.client_id, d1.item_sid, d1.dwh_valid_to AS dwh_valid_to, MIN(d2.dwh_valid_from) AS min_date FROM table d1 LEFT JOIN table d2 ON d1.client_id = d2.client_id AND d1.item_sid = d2.item_sid AND d1.dwh_valid_to >= d2.dwh_valid_from AND d1.dwh_valid_from < = d2.dwh_valid_to GROUP BY d1.client_id, d1.item_sid, d1.dwh_valid_to ) t GROUP BY t.client_id, t.item_sid, t.min_date;

Fonctions

Les sections suivantes répertorient les correspondances entre les fonctions Teradata et leurs équivalents dans BigQuery.

Fonctions d'agrégation

Le tableau suivant met en correspondance les fonctions d'agrégation, d'agrégation statistique et d'agrégation approximative courantes de Teradata avec leurs équivalents dans BigQuery. BigQuery propose les fonctions d'agrégation supplémentaires suivantes :

Teradata	BigQuery
`AVG`	`AVG`
`BITAND`	`BIT_AND`
`BITNOT`	Opérateur NOT (PAS) au niveau du bit (`~`)
`BITOR`	`BIT_OR`
`BITXOR`	`BIT_XOR`
`CORR`	`CORR`
`COUNT`	`COUNT`
`COVAR_POP`	`COVAR_POP`
`COVAR_SAMP`	`COVAR_SAMP`
`MAX`	`MAX`
`MIN`	`MIN`
`REGR_AVGX`	`AVG( IF(dep_var_expression is NULL OR ind_var_expression is NULL, NULL, ind_var_expression) )`
`REGR_AVGY`	`AVG( IF(dep_var_expression is NULL OR ind_var_expression is NULL, NULL, dep_var_expression) )`
`REGR_COUNT`	`SUM( IF(dep_var_expression is NULL OR ind_var_expression is NULL, NULL, 1) )`
`REGR_INTERCEPT`	`AVG(dep_var_expression) - AVG(ind_var_expression) * (COVAR_SAMP(ind_var_expression, dep_var_expression) / VARIANCE(ind_var_expression))`
`REGR_R2`	`(COUNT(dep_var_expression)* SUM(ind_var_expression * dep_var_expression) - SUM(dep_var_expression) * SUM(ind_var_expression)) / SQRT( (COUNT(ind_var_expression)* SUM(POWER(ind_var_expression, 2))* POWER(SUM(ind_var_expression),2))* (COUNT(dep_var_expression)* SUM(POWER(dep_var_expression, 2))* POWER(SUM(dep_var_expression), 2)))`
`REGR_SLOPE`	`- COVAR_SAMP(ind_var_expression, dep_var_expression) / VARIANCE(ind_var_expression)`
`REGR_SXX`	`SUM(POWER(ind_var_expression, 2)) - COUNT(ind_var_expression) * POWER(AVG(ind_var_expression),2)`
`REGR_SXY`	`SUM(ind_var_expression * dep_var_expression) - COUNT(ind_var_expression) * AVG(ind_var_expression) * AVG(dep_var_expression)`
`REGR_SYY`	`SUM(POWER(dep_var_expression, 2)) - COUNT(dep_var_expression) * POWER(AVG(dep_var_expression),2)`
`SKEW`	Fonction définie par l'utilisateur personnalisée.
`STDDEV_POP`	`STDDEV_POP`
`STDDEV_SAMP`	`STDDEV_SAMP, STDDEV`
`SUM`	`SUM`
`VAR_POP`	`VAR_POP`
`VAR_SAMP`	`VAR_SAMP, VARIANCE`

Fonctions d'analyse et de fenêtrage

Le tableau suivant met en correspondance les fonctions analytiques de Teradata et agrège les fonctions analytiques avec les fonctions de fenêtrage équivalentes de BigQuery. BigQuery propose les fonctions supplémentaires suivantes:

Teradata	BigQuery
`ARRAY_AGG`	`ARRAY_AGG`
`ARRAY_CONCAT, (\|\| operator)`	`ARRAY_CONCAT_AGG, (\|\| operator)`
`BITAND`	`BIT_AND`
`BITNOT`	Opérateur NOT (PAS) au niveau du bit (`~`)
`BITOR`	`BIT_OR`
`BITXOR`	`BIT_XOR`
`CORR`	`CORR`
`COUNT`	`COUNT`
`COVAR_POP`	`COVAR_POP`
`COVAR_SAMP`	`COVAR_SAMP`
`CUME_DIST`	`CUME_DIST`
`DENSE_RANK` (ANSI)	`DENSE_RANK`
`FIRST_VALUE`	`FIRST_VALUE`
`LAST_VALUE`	`LAST_VALUE`
`MAX`	`MAX`
`MIN`	`MIN`
`PERCENT_RANK`	`PERCENT_RANK`
`PERCENTILE_CONT` `PERCENTILE_DISC`	`PERCENTILE_CONT` `PERCENTILE_DISC`
`RANK` (ANSI)	`RANK`
`ROW_NUMBER`	`ROW_NUMBER`
`STDDEV_POP`	`STDDEV_POP`
`STDDEV_SAMP`	`STDDEV_SAMP, STDDEV`
`SUM`	`SUM`
`VAR_POP`	`VAR_POP`
`VAR_SAMP`	`VAR_SAMP, VARIANCE`

Fonctions de date/heure

Le tableau suivant met en correspondance les fonctions de date/heure courantes de Teradata avec leurs équivalents dans BigQuery. BigQuery propose les fonctions de date/heure supplémentaires suivantes :

Teradata	BigQuery
`ADD_MONTHS`	`DATE_ADD, TIMESTAMP_ADD`
`CURRENT_DATE`	`CURRENT_DATE`
`CURRENT_TIME`	`CURRENT_TIME`
`CURRENT_TIMESTAMP`	`CURRENT_TIMESTAMP`
`DATE + k`	`DATE_ADD(date_expression, INTERVAL k DAY)`
`DATE - k`	`DATE_SUB(date_expression, INTERVAL k DAY)`
`EXTRACT`	`EXTRACT(DATE), EXTRACT(TIMESTAMP)`
	`FORMAT_DATE`
	`FORMAT_DATETIME`
	`FORMAT_TIME`
	`FORMAT_TIMESTAMP`
`LAST_DAY`	`LAST_DAY` Remarque : Cette fonction accepte les expressions d'entrée `DATE` et `DATETIME`.
`MONTHS_BETWEEN`	`DATE_DIFF(date_expression, date_expression, MONTH)`
`NEXT_DAY`	`DATE_ADD( DATE_TRUNC( date_expression, WEEK(day_value) ), INTERVAL 1 WEEK )`
`OADD_MONTHS`	`DATE_SUB( DATE_TRUNC( DATE_ADD( date_expression, INTERVAL num_months MONTH ), MONTH ), INTERVAL 1 DAY )`
`td_day_of_month`	`EXTRACT(DAY FROM date_expression) EXTRACT(DAY FROM timestamp_expression)`
`td_day_of_week`	`EXTRACT(DAYOFWEEK FROM date_expression) EXTRACT(DAYOFWEEK FROM timestamp_expression)`
`td_day_of_year`	`EXTRACT(DAYOFYEAR FROM date_expression) EXTRACT(DAYOFYEAR FROM timestamp_expression)`
`td_friday`	`DATE_TRUNC( date_expression, WEEK(FRIDAY) )`
`td_monday`	`DATE_TRUNC( date_expression, WEEK(MONDAY) )`
`td_month_begin`	`DATE_TRUNC(date_expression, MONTH)`
`td_month_end`	`DATE_SUB( DATE_TRUNC( DATE_ADD( date_expression, INTERVAL 1 MONTH ), MONTH ), INTERVAL 1 DAY )`
`td_month_of_calendar`	`(EXTRACT(YEAR FROM date_expression) - 1900) * 12 + EXTRACT(MONTH FROM date_expression)`
`td_month_of_quarter`	`EXTRACT(MONTH FROM date_expression) - ((EXTRACT(QUARTER FROM date_expression) - 1) * 3)`
`td_month_of_year`	`EXTRACT(MONTH FROM date_expression) EXTRACT(MONTH FROM timestamp_expression)`
`td_quarter_begin`	`DATE_TRUNC(date_expression, QUARTER)`
`td_quarter_end`	`DATE_SUB( DATE_TRUNC( DATE_ADD( date_expression, INTERVAL 1 QUARTER ), QUARTER ), INTERVAL 1 DAY )`
`td_quarter_of_calendar`	`(EXTRACT(YEAR FROM date_expression) - 1900) * 4 + EXTRACT(QUARTER FROM date_expression)`
`td_quarter_of_year`	`EXTRACT(QUARTER FROM date_expression) EXTRACT(QUARTER FROM timestamp_expression)`
`td_saturday`	`DATE_TRUNC( date_expression, WEEK(SATURDAY) )`
`td_sunday`	`DATE_TRUNC( date_expression, WEEK(SUNDAY) )`
`td_thursday`	`DATE_TRUNC( date_expression, WEEK(THURSDAY) )`
`td_tuesday`	`DATE_TRUNC( date_expression, WEEK(TUESDAY) )`
`td_wednesday`	`DATE_TRUNC( date_expression, WEEK(WEDNESDAY) )`
`td_week_begin`	`DATE_TRUNC(date_expression, WEEK)`
`td_week_end`	`DATE_SUB( DATE_TRUNC( DATE_ADD( date_expression, INTERVAL 1 WEEK ), WEEK ), INTERVAL 1 DAY )`
`td_week_of_calendar`	`(EXTRACT(YEAR FROM date_expression) - 1900) * 52 + EXTRACT(WEEK FROM date_expression)`
`td_week_of_month`	`EXTRACT(WEEK FROM date_expression) - EXTRACT(WEEK FROM DATE_TRUNC(date_expression, MONTH))`
`td_week_of_year`	`EXTRACT(WEEK FROM date_expression) EXTRACT(WEEK FROM timestamp_expression)`
`td_weekday_of_month`	`CAST( CEIL( EXTRACT(DAY FROM date_expression) / 7 ) AS INT64 )`
`td_year_begin`	`DATE_TRUNC(date_expression, YEAR)`
`td_year_end`	`DATE_SUB( DATE_TRUNC( DATE_ADD( date_expression, INTERVAL 1 YEAR ), YEAR ), INTERVAL 1 DAY )`
`td_year_of_calendar`	`EXTRACT(YEAR FROM date_expression)`
`TO_DATE`	`PARSE_DATE`
`TO_TIMESTAMP`	`PARSE_TIMESTAMP`
`TO_TIMESTAMP_TZ`	`PARSE_TIMESTAMP`

Fonctions de chaîne

Le tableau suivant met en correspondance les fonctions de chaîne de Teradata avec leurs équivalents dans BigQuery. BigQuery propose les fonctions de chaîne supplémentaires suivantes :

Teradata	BigQuery
`ASCII`	`TO_CODE_POINTS(string_expression)[OFFSET(0)]`
`CHAR2HEXINT`	`TO_HEX`
`CHARACTER LENGTH`	`CHAR_LENGTH`
`CHARACTER LENGTH`	`CHARACTER_LENGTH`
`CHR`	`CODE_POINTS_TO_STRING( [mod(numeric_expression, 256)] )`
`CONCAT, (\|\| operator)`	`CONCAT, (\|\| operator)`
`CSV`	Fonction définie par l'utilisateur personnalisée.
`CSVLD`	Fonction définie par l'utilisateur personnalisée.
`FORMAT`	`FORMAT`
`INDEX`	`STRPOS(string, substring)`
`INITCAP`	`INITCAP`
`INSTR`	Fonction définie par l'utilisateur personnalisée.
`LEFT`	`SUBSTR(source_string, 1, length)`
`LENGTH`	`LENGTH`
`LOWER`	`LOWER`
`LPAD`	`LPAD`
`LTRIM`	`LTRIM`
`NGRAM`	Fonction définie par l'utilisateur personnalisée.
`NVP`	Fonction définie par l'utilisateur personnalisée.
`OREPLACE`	`REPLACE`
`OTRANSLATE`	Fonction définie par l'utilisateur personnalisée.
`POSITION`	`STRPOS(string, substring)`
`REGEXP_INSTR`	`STRPOS(source_string, REGEXP_EXTRACT(source_string, regexp_string))` Remarque : Renvoie la première occurrence.
`REGEXP_REPLACE`	`REGEXP_REPLACE`
`REGEXP_SIMILAR`	`IF(REGEXP_CONTAINS,1,0)`
`REGEXP_SUBSTR`	`REGEXP_EXTRACT, REGEXP_EXTRACT_ALL`
`REGEXP_SPLIT_TO_TABLE`	Fonction définie par l'utilisateur personnalisée.
`REVERSE`	`REVERSE`
`RIGHT`	`SUBSTR(source_string, -1, length)`
`RPAD`	`RPAD`
`RTRIM`	`RTRIM`
`STRTOK` Remarque : Chaque caractère de l'argument de chaîne "delimiter" est considéré comme un caractère de délimitation distinct. Le délimiteur par défaut est un espace.	`SPLIT(instring, delimiter)[ORDINAL(tokennum)]` Remarque : L'argument de chaîne delimiter entier est utilisé comme un délimiteur unique. Le délimiteur par défaut est une virgule.
`STRTOK_SPLIT_TO_TABLE`	Fonction définie par l'utilisateur personnalisée.
`SUBSTRING` `SUBSTR`	`SUBSTR`
`TRIM`	`TRIM`
`UPPER`	`UPPER`

Fonctions mathématiques

Le tableau suivant met en correspondance les fonctions mathématiques de Teradata avec leurs équivalents dans BigQuery. BigQuery propose les fonctions mathématiques supplémentaires suivantes :

Teradata	BigQuery
`ABS`	`ABS`
`ACOS`	`ACOS`
`ACOSH`	`ACOSH`
`ASIN`	`ASIN`
`ASINH`	`ASINH`
`ATAN`	`ATAN`
`ATAN2`	`ATAN2`
`ATANH`	`ATANH`
`CEILING`	`CEIL`
`CEILING`	`CEILING`
`COS`	`COS`
`COSH`	`COSH`
`EXP`	`EXP`
`FLOOR`	`FLOOR`
`GREATEST`	`GREATEST`
`LEAST`	`LEAST`
`LN`	`LN`
`LOG`	`LOG`
`MOD` (opérateur `%`)	`MOD`
`NULLIFZERO`	`NULLIF(expression, 0)`
`POWER` (opérateur `**`)	`POWER, POW`
`RANDOM`	`RAND`
`ROUND`	`ROUND`
`SIGN`	`SIGN`
`SIN`	`SIN`
`SINH`	`SINH`
`SQRT`	`SQRT`
`TAN`	`TAN`
`TANH`	`TANH`
`TRUNC`	`TRUNC`
`ZEROIFNULL`	`IFNULL(expression, 0), COALESCE(expression, 0)`

Syntaxe LMD

Cette section traite des différences de syntaxe du langage de manipulation de données entre Teradata et BigQuery.

Instruction `INSERT`

La plupart des instructions INSERT Teradata sont compatibles avec BigQuery. Le tableau suivant présente les exceptions.

Les scripts LMD dans BigQuery présentent une sémantique de cohérence légèrement différente de celle des instructions équivalentes dans Teradata. Pour obtenir une présentation de l'isolation d'instantané et de la gestion des sessions et des transactions, consultez la section CREATE INDEX plus loin dans ce document.

Teradata BigQuery

INSERT INTO table VALUES (...); INSERT INTO table (...) VALUES (...);

Teradata propose un mot clé DEFAULT pour les colonnes n'autorisant pas les valeurs nulles.

Remarque : Dans BigQuery, l'omission des noms de colonnes dans l'instruction INSERT ne fonctionne que si les valeurs de toutes les colonnes de la table cible sont incluses dans l'ordre croissant en fonction de leurs positions ordinales.

Teradata	BigQuery
`INSERT INTO table VALUES (...);`	`INSERT INTO table (...) VALUES (...);` Teradata propose un mot clé `DEFAULT` pour les colonnes n'autorisant pas les valeurs nulles. Remarque : Dans BigQuery, l'omission des noms de colonnes dans l'instruction `INSERT` ne fonctionne que si les valeurs de toutes les colonnes de la table cible sont incluses dans l'ordre croissant en fonction de leurs positions ordinales.
`INSERT INTO table VALUES (1,2,3); INSERT INTO table VALUES (4,5,6); INSERT INTO table VALUES (7,8,9);`	`INSERT INTO table VALUES (1,2,3), (4,5,6), (7,8,9);` Teradata a un concept de requête multi-instructions (MSR, multi-statement request), qui envoie plusieurs instructions `INSERT` à la fois. Dans BigQuery, cela n'est pas recommandé en raison de la limite de transaction implicite entre les instructions. Utilisez plutôt une instruction `INSERT` multivaleur. BigQuery autorise les instructions `INSERT` simultanées, mais peut mettre en file d'attente les instructions `UPDATE`. Pour améliorer les performances, pensez à recourir aux approches suivantes : Combinez plusieurs lignes en une seule instruction `INSERT` au lieu d'avoir une ligne par opération `INSERT`. Combinez plusieurs instructions LMD (y compris `INSERT`) à l'aide d'une instruction `MERGE`. Utilisez `CREATE TABLE ... AS SELECT` pour créer et remplir de nouvelles tables au lieu de `UPDATE` ou `DELETE`, en particulier lors de l'interrogation de champs partitionnés ou de rollback ou restauration.


INSERT INTO table VALUES (1,2,3);

INSERT INTO table VALUES (4,5,6);

INSERT INTO table VALUES (7,8,9);


INSERT INTO
table VALUES (1,2,3),

                         (4,5,6),

                         (7,8,9);

Teradata a un concept de requête multi-instructions (MSR, multi-statement request), qui envoie plusieurs instructions INSERT à la fois. Dans BigQuery, cela n'est pas recommandé en raison de la limite de transaction implicite entre les instructions. Utilisez plutôt une instruction INSERT multivaleur.

BigQuery autorise les instructions INSERT simultanées, mais peut mettre en file d'attente les instructions UPDATE. Pour améliorer les performances, pensez à recourir aux approches suivantes :

Combinez plusieurs lignes en une seule instruction INSERT au lieu d'avoir une ligne par opération INSERT.
Combinez plusieurs instructions LMD (y compris INSERT) à l'aide d'une instruction MERGE.
Utilisez CREATE TABLE ... AS SELECT pour créer et remplir de nouvelles tables au lieu de UPDATE ou DELETE, en particulier lors de l'interrogation de champs partitionnés ou de rollback ou restauration.

Instruction `UPDATE`

La plupart des instructions UPDATE Teradata sont compatibles avec BigQuery, à l'exception des éléments suivants :

Lorsque vous utilisez une clause FROM, l'ordre des clauses FROM et SET est inversé dans Teradata et BigQuery.
Dans Google SQL, chaque instruction UPDATE doit inclure le mot clé WHERE, suivi d'une condition. Pour mettre à jour toutes les lignes de la table, utilisez WHERE true.

Nous vous recommandons de regrouper plusieurs mutations LMD au lieu d'utiliser des instructions UPDATE et INSERT uniques. Les scripts LMD dans BigQuery présentent une sémantique de cohérence légèrement différente de celle des instructions équivalentes dans Teradata. Pour obtenir une présentation de l'isolation d'instantané et de la gestion des sessions et des transactions, consultez la section CREATE INDEX plus loin dans ce document.

Le tableau suivant présente les instructions UPDATE Teradata et les instructions BigQuery qui effectuent les mêmes tâches.

Pour en savoir plus sur l'instruction UPDATE dans BigQuery, consultez les exemples d'instructions UPDATE BigQuery dans la documentation sur le LMD.

Teradata		BigQuery
`UPDATE table_A FROM table_A, table_B SET y = table_B.y, z = table_B.z + 1 WHERE table_A.x = table_B.x AND table_A.y IS NULL;`		`UPDATE table_A SET y = table_B.y, z = table_B.z + 1 FROM table_B WHERE table_A.x = table_B.x AND table_A.y IS NULL;`
`UPDATE table alias SET x = x + 1 WHERE f(x) IN (0, 1);`		`UPDATE table SET x = x + 1 WHERE f(x) IN (0, 1);`
`UPDATE table_A FROM table_A, table_B, B SET z = table_B.z WHERE table_A.x = table_B.x AND table_A.y = table_B.y;`		`UPDATE table_A SET z = table_B.z FROM table_B WHERE table_A.x = table_B.x AND table_A.y = table_B.y;`

Instructions `DELETE` et `TRUNCATE`

Les instructions DELETE et TRUNCATE permettent de supprimer des lignes d'une table sans que cela n'affecte son schéma ou ses index. TRUNCATE n'est utilisé ni dans Teradata, ni dans BigQuery. Cependant, vous pouvez utiliser les instructions DELETE pour obtenir le même effet.

Dans BigQuery, l'instruction DELETE doit comporter une clause WHERE. Pour supprimer (tronquer) toutes les lignes de la table, utilisez WHERE true. Pour accélérer les opérations de troncation des tables très volumineuses, nous vous recommandons d'utiliser l'instruction CREATE OR REPLACE TABLE ... AS SELECT, en utilisant LIMIT 0 sur la même table pour la remplacer. Cependant, veillez à ajouter manuellement les informations de partitionnement et de clustering lorsque vous utilisez cette instruction.

Teradata élimine les lignes supprimées ultérieurement. Cela signifie que les opérations DELETE sont au départ plus rapides que dans BigQuery, mais qu'elles nécessitent ensuite des ressources, en particulier les opérations DELETE à grande échelle qui ont un impact sur la majeure partie d'une table. Pour utiliser une approche similaire dans BigQuery, nous vous suggérons de réduire le nombre d'opérations DELETE, par exemple en copiant les lignes à ne pas supprimer dans une nouvelle table. Vous pouvez également supprimer des partitions entières. Ces deux options sont conçues pour être plus rapides que les mutations LMD atomiques.

Pour en savoir plus sur l'instruction DELETE dans BigQuery, consultez les exemples d'instructions DELETE dans la documentation sur le LMD.

Teradata	BigQuery
`BEGIN TRANSACTION; LOCKING TABLE table_A FOR EXCLUSIVE; DELETE FROM table_A; INSERT INTO table_A SELECT * FROM table_B; END TRANSACTION;`	Le remplacement du contenu d'une table par un résultat de requête équivaut à une transaction. Pour ce faire, vous pouvez utiliser une opération de requête ou une opération de copie. Avec une opération de requête : `bq query --replace --destination_table table_A 'SELECT * FROM table_B';` Avec une opération de copie : `bq cp -f table_A table_B`
`DELETE database.table ALL;`	`DELETE FROM table WHERE TRUE;` Ou, pour les tables très volumineuses, une méthode plus rapide : `CREATE OR REPLACE table AS SELECT * FROM table LIMIT 0;`

Instruction `MERGE`

L'instruction MERGE peut combiner les opérations INSERT, UPDATE et DELETE en une seule instruction "upsert" et effectuer les opérations de manière atomique. L'opération MERGE doit correspondre à une ligne source au maximum pour chaque ligne cible. BigQuery et Teradata suivent tous deux la syntaxe ANSI.

L'opération MERGE de Teradata est limitée à la mise en correspondance des clés primaires dans un processeur de module d'accès (AMP, access module processor). En revanche, BigQuery n'a aucune limite de taille ou de colonne pour les opérations MERGE. Par conséquent, l'utilisation de MERGE est une optimisation utile. Toutefois, si l'instruction MERGE est principalement une suppression de grande taille, consultez les optimisations pour DELETE plus loin dans ce document.

Les scripts LMD dans BigQuery présentent une sémantique de cohérence légèrement différente de celle des instructions équivalentes dans Teradata. Par exemple, les tables SET de Teradata en mode session peuvent ignorer les doubles lors d'une opération MERGE. Pour obtenir une présentation de la gestion des tables MULTISET et SET, de l'isolation d'instantané et de la gestion des sessions et des transactions, consultez la section CREATE INDEX plus loin dans ce document.

Variables affectées par les lignes

Dans Teradata, la variable ACTIVITY_COUNT est une extension ANSI SQL Teradata renseignée avec le nombre de lignes affectées par une instruction LMD.

La variable système @@row_count de la fonctionnalité de création de scripts offre une fonction similaire. Dans BigQuery, il est plus courant de vérifier la valeur renvoyée numDmlAffectedRows dans les journaux d'audit ou dans les vues INFORMATION_SCHEMA.

Syntaxe LDD

Cette section traite des différences de syntaxe du langage de définition de données entre Teradata et BigQuery.

Instruction `CREATE TABLE`

La plupart des instructions CREATE TABLE Teradata sont compatibles avec BigQuery, à l'exception des éléments de syntaxe suivants, qui ne sont pas utilisés dans BigQuery :

MULTISET. Consultez la section CREATE INDEX.
VOLATILE. Consultez la section Tables temporaires.
[NO] FALLBACK. Consultez la section Rollback.
[NO] BEFORE JOURNAL, [NO] AFTER JOURNAL
CHECKSUM = DEFAULT | val
DEFAULT MERGEBLOCKRATIO
PRIMARY INDEX (col, ...). Consultez la section CREATE INDEX.
UNIQUE PRIMARY INDEX. Consultez la section CREATE INDEX.
CONSTRAINT
DEFAULT
IDENTITY

Pour en savoir plus sur l'instruction CREATE TABLE dans BigQuery, consultez les exemples d'instructions CREATE BigQuery dans la documentation sur le LMD.

Attributs et options de colonne

Les spécifications de colonne suivantes pour l'instruction CREATE TABLE ne sont pas utilisées dans BigQuery :

FORMAT 'format'. Consultez la section Mise en forme des types de données Teradata.
CHARACTER SET name. BigQuery utilise toujours l'encodage UTF-8.
[NOT] CASESPECIFIC
COMPRESS val | (val, ...)

Teradata étend la norme ANSI avec une option de colonne TITLE. Cette fonctionnalité peut être mise en œuvre d'une manière similaire dans BigQuery à l'aide de la description de colonne, comme indiqué dans le tableau suivant. Notez que cette option n'est pas disponible pour les vues.

Teradata	BigQuery
`CREATE TABLE table ( col1 VARCHAR(30) TITLE 'column desc' );`	`CREATE TABLE dataset.table ( col1 STRING OPTIONS(description="column desc") );`

Tables temporaires

Teradata accepte les tables volatiles, qui sont souvent utilisées pour stocker des résultats intermédiaires dans des scripts. Il existe plusieurs façons d'obtenir une fonctionnalité semblable aux tables volatiles dans BigQuery :

CREATE TEMPORARY TABLE peut être utilisé dans la fonctionnalité de création de scripts et est valide pendant la durée de vie du script. Si la table doit exister au-delà de la durée de vie d'un script, vous pouvez utiliser les autres options de cette liste.
Valeur TTL de l'ensemble de données : créez un ensemble de données ayant une durée de vie courte (par exemple, 1 heure) afin que les tables créées dans cet ensemble de données soient effectivement temporaires, car elles ne persisteront pas au-delà de la durée de vie d'un script. Vous pouvez ajouter le préfixe temp à tous les noms de tables de cet ensemble de données pour indiquer clairement que les tables sont temporaires.
Valeur TTL de la table : créez une table ayant une durée de vie courte à l'aide d'instructions LDD semblables à ce qui suit :
```
CREATE TABLE temp.name (col1, col2, ...)
OPTIONS(expiration_timestamp=TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL 1 HOUR));
```
Clause WITH : si une table temporaire n'est nécessaire que dans le même bloc, utilisez un résultat temporaire à l'aide d'une sous-requête ou d'une instruction WITH. C'est l'option la plus efficace.

Un modèle souvent utilisé dans les scripts Teradata (BTEQ) consiste à créer une table permanente, à y insérer une valeur, à utiliser cette table comme table temporaire dans les instructions en cours, puis à la supprimer ou à la tronquer. En effet, la table est utilisée comme variable constante (sémaphore). Cette approche n'est pas efficace dans BigQuery, et nous vous recommandons d'utiliser plutôt des variables réelles dans la fonctionnalité de création de scripts ou CREATE OR REPLACE avec la syntaxe de requête AS SELECT pour créer une table contenant déjà des valeurs.

Instruction `CREATE VIEW`

Le tableau suivant présente les équivalences entre Teradata et BigQuery pour l'instruction CREATE VIEW. Les clauses de verrouillage de table telles que LOCKING ROW FOR ACCESS ne sont pas nécessaires dans BigQuery.

Teradata	BigQuery	Remarques
`CREATE VIEW view_name AS SELECT ...`	`CREATE VIEW view_name AS SELECT ...`
`REPLACE VIEW view_name AS SELECT ...`	`CREATE OR REPLACE VIEW view_name AS SELECT ...`
Non compatible	`CREATE VIEW IF NOT EXISTS OPTIONS(view_option_list) AS SELECT ...`	Crée une vue uniquement si elle n'existe pas dans l'ensemble de données spécifié.

Instruction `CREATE [UNIQUE] INDEX`

Teradata requiert des index pour toutes les tables et requiert des solutions spéciales telles que les tables MULTISET et NoPI afin de pouvoir utiliser des données non uniques ou non indexées.

BigQuery ne nécessite pas d'index. Cette section décrit les méthodes dans BigQuery permettant de créer des fonctionnalités semblables à l'utilisation des index dans Teradata, en cas de besoin réel d'une logique métier.

Indexation à des fins de performances

Comme il s'agit d'une base de données orientée colonnes avec optimisation des requêtes et du stockage, BigQuery n'a pas besoin d'index explicites. BigQuery fournit des fonctionnalités telles que le partitionnement et le clustering, ainsi que des champs imbriqués, qui peuvent améliorer l'efficacité et les performances des requêtes en optimisant le stockage des données.

Teradata n'est pas compatible avec les vues matérialisées. Cependant, il propose des index de jointure à l'aide de l'instruction CREATE JOIN INDEX, qui matérialise essentiellement les données nécessaires à une jointure. BigQuery n'a pas besoin d'index matérialisés pour accélérer les performances, tout comme il n'a pas besoin d'espace de spool dédié aux jointures.

Pour les autres cas d'optimisation, vous pouvez utiliser des vues matérialisées.

Indexation à des fins de cohérence (UNIQUE, PRIMARY INDEX)

Dans Teradata, un index unique peut être utilisé pour empêcher que des lignes contiennent des clés non uniques dans une table. Si un processus tente d'insérer ou de mettre à jour des données ayant une valeur figurant déjà dans l'index, l'opération échoue avec une violation d'index (tables MULTISET) ou les ignore en mode silencieux (tables SET).

Comme BigQuery ne fournit pas d'index explicites, une instruction MERGE peut être utilisée à la place pour insérer uniquement des enregistrements uniques dans une table cible à partir d'une table intermédiaire tout en supprimant les enregistrements en double. Cependant, il est impossible d'empêcher un utilisateur disposant de droits de modification d'insérer un enregistrement en double, car BigQuery ne se verrouille jamais pendant les opérations INSERT. Pour générer une erreur liée à des enregistrements en double dans BigQuery, vous pouvez utiliser une instruction MERGE à partir d'une table intermédiaire, comme indiqué dans l'exemple suivant.

Teradata		BigQuery
`CREATE [UNIQUE] INDEX name;`		MERGE `prototype.FIN_MERGE` t USING `prototype.FIN_TEMP_IMPORT` m ON t.col1 = m.col1 AND t.col2 = m.col2 WHEN MATCHED THEN UPDATE SET t.col1 = ERROR(CONCAT('Encountered error for ', m.col1, ' ', m.col2)) WHEN NOT MATCHED THEN INSERT (col1,col2,col3,col4,col5,col6,col7,col8) VALUES(col1,col2,col3,col4,col5,col6,CURRENT_TIMESTAMP(),CURRENT_TIMESTAMP());

Le plus souvent, les utilisateurs préfèrent supprimer les doubles indépendamment afin de détecter les erreurs dans les systèmes en aval.
BigQuery n'est pas compatible avec les colonnes DEFAULT et IDENTITY (séquences).

Indexation pour obtenir le verrouillage

Teradata fournit des ressources dans le processeur de module d'accès (AMP). Les requêtes peuvent consommer les ressources de tous les AMP, d'un seul AMP ou d'un groupe d'AMP. Les instructions LDD consomment les ressources de tous les AMP et sont donc semblables à un verrou LDD global. BigQuery ne dispose pas d'un mécanisme de verrouillage comme celui-ci et peut exécuter des requêtes simultanées et des instructions INSERT dans la limite de votre quota. Seules les instructions LMD UPDATE simultanées ont des conséquences en termes de simultanéité : les opérations UPDATE réalisées sur la même partition sont mises en file d'attente pour garantir l'isolation d'instantané. Vous n'avez donc pas besoin du verrouillage pour empêcher les lectures fantômes ou les mises à jour perdues.

En raison de ces différences, les éléments Teradata suivants ne sont pas utilisés dans BigQuery :

ON COMMIT DELETE ROWS;
ON COMMIT PRESERVE ROWS;

Instructions SQL procédurales

Cette section explique comment convertir les instructions SQL procédurales utilisées dans des procédures stockées, des fonctions et des déclencheurs de Teradata en scripts, procédures ou fonctions définies par l'utilisateur BigQuery. Les administrateurs système peuvent vérifier tous ces éléments à l'aide des vues INFORMATION_SCHEMA.

Instruction `CREATE PROCEDURE`

Les procédures stockées sont compatibles avec la fonctionnalité de création de scripts BigQuery.

Dans BigQuery, cette fonctionnalité fait référence à toute utilisation d'instructions de contrôle, tandis que les procédures sont des scripts nommés (avec des arguments, si nécessaire) qui peuvent être appelés à partir d'autres scripts et stockés de manière permanente, en cas de besoin. Une fonction définie par l'utilisateur peut également être écrite en JavaScript.

Teradata	BigQuery
`CREATE PROCEDURE`	`CREATE PROCEDURE` si un nom est requis. Sinon, utilisez l'instruction sous le bloc `BEGIN` ou sur une seule ligne avec `CREATE TEMP FUNCTION`.
`REPLACE PROCEDURE`	`CREATE OR REPLACE PROCEDURE`
`CALL`	`CALL`

Les sections suivantes décrivent comment convertir des instructions procédurales Teradata existantes en instructions de script BigQuery ayant des fonctionnalités similaires.

Déclaration et attribution de variables

Les variables BigQuery sont valides pendant toute la durée de vie du script.

Teradata	BigQuery
`DECLARE`	`DECLARE`
`SET`	`SET`

Gestionnaires de conditions d'erreur

Teradata utilise des gestionnaires sur les codes d'état dans les procédures à des fins de contrôle des erreurs. Dans BigQuery, la gestion des erreurs est une fonctionnalité essentielle du flux de contrôle principal, semblable à ce que d'autres langages fournissent avec les blocs TRY ... CATCH.

Teradata	BigQuery
`DECLARE EXIT HANDLER FOR SQLEXCEPTION`	`BEGIN ... EXCEPTION WHEN ERROR THEN`
`SIGNAL sqlstate`	`RAISE message`
`DECLARE CONTINUE HANDLER FOR SQLSTATE VALUE 23505;`	Les gestionnaires d'exceptions qui se déclenchent pour certaines conditions d'erreur ne sont pas utilisés par BigQuery. Nous vous recommandons d'utiliser les instructions `ASSERT` dans lesquelles les conditions de sortie sont utilisées pour les vérifications préalables ou le débogage, car elles sont conformes à la norme ANSI SQL:2011.

La variable SQLSTATE de Teradata est semblable à la variable système @@error de BigQuery. Dans BigQuery, il est plus courant de rechercher les erreurs à l'aide de la journalisation d'audit ou des vues INFORMATION_SCHEMA.

Déclarations et opérations de curseurs

Étant donné que BigQuery n'accepte pas les curseurs ni les sessions, il n'utilise pas les instructions suivantes :

DECLARE cursor_name CURSOR [FOR | WITH] ...
PREPARE stmt_id FROM sql_str;
OPEN cursor_name [USING var, ...];
FETCH cursor_name INTO var, ...;
CLOSE cursor_name;

Instructions SQL dynamiques

La fonctionnalité de script de BigQuery est compatible avec les instructions SQL dynamiques telles que celles présentées dans le tableau suivant.

Teradata	BigQuery
`EXECUTE IMMEDIATE sql_str;`	`EXECUTE IMMEDIATE sql_str;`
`EXECUTE stmt_id [USING var,...];`	`EXECUTE IMMEDIATE stmt_id USING var;`

Les instructions SQL dynamiques suivantes ne sont pas utilisées dans BigQuery :

PREPARE stmt_id FROM sql_str;

Instructions de flux de contrôle

La fonctionnalité de création de scripts de BigQuery accepte les instructions de flux de contrôle telles que celles présentées dans le tableau suivant.

Teradata	BigQuery
`IF condition THEN stmts ELSE stmts END IF`	`IF condition THEN stmts ELSE stmts END IF`
`label_name: LOOP stmts END LOOP label_name;`	Les constructions de blocs de style GOTO ne sont pas utilisées dans BigQuery. Nous vous recommandons de les réécrire en tant que fonctions définies par l'utilisateur ou d'utiliser des instructions `ASSERT` où elles sont utilisées pour le traitement des erreurs.
`REPEAT stmts UNTIL condition END REPEAT;`	`WHILE condition DO stmts END WHILE`
`LEAVE outer_proc_label;`	L'instruction `LEAVE` n'est pas utilisée pour les blocs de style GOTO. Elle est utilisée comme synonyme de `BREAK` pour quitter une boucle `WHILE`.
`LEAVE label;`	L'instruction `LEAVE` n'est pas utilisée pour les blocs de style GOTO. Elle est utilisée comme synonyme de `BREAK` pour quitter une boucle `WHILE`.
`WITH RECURSIVE temp_table AS ( ... );`	Les requêtes récurrentes (également appelées expressions de table commune (CTE) récurrentes) ne sont pas utilisées dans BigQuery. Elles peuvent être réécrites à l'aide de tableaux de `UNION ALL`.

Les instructions de flux de contrôle suivantes ne sont pas utilisées dans BigQuery, car BigQuery n'utilise pas de curseur ni de session :

FOR var AS SELECT ... DO stmts END FOR;
FOR var AS cur CURSOR FOR SELECT ... DO stmts END FOR;

Instructions SQL de métadonnées et de transactions

Teradata	BigQuery
`HELP TABLE table_name;` `HELP VIEW view_name;`	`SELECT * EXCEPT(is_generated, generation_expression, is_stored, is_updatable) FROM mydataset.INFORMATION_SCHEMA.COLUMNS; WHERE table_name=table_name` La même requête est valide pour obtenir des informations de colonne pour les vues. Pour en savoir plus, consultez la vue Colonnes dans BigQuery `INFORMATION_SCHEMA`.
`SELECT * FROM dbc.tables WHERE tablekind = 'T';` (vue DBC Teradata)	`SELECT * EXCEPT(is_typed) FROM mydataset.INFORMATION_SCHEMA.TABLES;` Pour en savoir plus, consultez la page Présentation des vues `INFORMATION_SCHEMA` de BigQuery.
`HELP STATISTICS table_name;`	`APPROX_COUNT_DISTINCT(col)`
`COLLECT STATS USING SAMPLE ON table_name column (...);`	Non utilisé dans BigQuery.
`LOCKING TABLE table_name FOR EXCLUSIVE;`	BigQuery utilise toujours l'isolation d'instantané. Pour en savoir plus, consultez la section Garanties de cohérence plus loin dans ce document.
`SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL ...`	BigQuery utilise toujours l'isolation d'instantané. Pour en savoir plus, consultez la section Garanties de cohérence plus loin dans ce document.
`BEGIN TRANSACTION; SELECT ... END TRANSACTION;`	BigQuery utilise toujours l'isolation d'instantané. Pour en savoir plus, consultez la section Garanties de cohérence plus loin dans ce document.
`EXPLAIN ...`	Non utilisé dans BigQuery. L'explication du plan de requête dans l'interface utilisateur Web de BigQuery et l'allocation d'emplacements visible dans les vues `INFORMATION_SCHEMA` et dans la journalisation d'audit dans Cloud Monitoring sont des fonctionnalités similaires.

Instructions SQL multi-instructions et multilignes

Teradata et BigQuery acceptent les transactions (sessions) et donc les instructions séparées par un point-virgule qui sont systématiquement exécutées ensemble. Pour plus d'informations, consultez la section Transactions multi-instructions.

Codes et messages d'erreur

Les codes d'erreur Teradata et BigQuery sont différents. En fournissant une API REST, BigQuery repose principalement sur des codes d'état HTTP et des messages d'erreur détaillés.

Si votre logique d'application détecte actuellement les erreurs suivantes, essayez d'éliminer la source de l'erreur, car BigQuery ne renverra pas les mêmes codes d'erreur.

SQLSTATE = '02000' : "Ligne introuvable"
SQLSTATE = '21000' : "Violation de cardinalité (index unique)"
SQLSTATE = '22000' : "Violation de données (type de données)"
SQLSTATE = '23000' : "Violation de contrainte"

Dans BigQuery, il est plus courant d'utiliser les vues INFORMATION_SCHEMA ou la journalisation d'audit pour afficher le détail des erreurs.

Pour en savoir plus sur la gestion des erreurs dans la fonctionnalité de création de scripts, consultez les sections suivantes.

Garanties de cohérence et isolation de transaction

Teradata et BigQuery sont tous deux atomiques, c'est-à-dire conformes à la norme ACID au niveau de chaque mutation sur de nombreuses lignes. Par exemple, une opération MERGE est complètement atomique, même avec plusieurs valeurs insérées et mises à jour.

Transactions

Teradata fournit le niveau d'isolation de transaction "Read Uncommitted" (lecture des données non validées) ou "Serializable" (sérialisable) lors de l'exécution en mode session (au lieu du mode autocommit). Dans le meilleur des cas, Teradata obtient une isolation strictement sérialisable en utilisant un verrouillage pessimiste sur un hachage de ligne dans toutes les colonnes de lignes de toutes les partitions. Les interblocages sont possibles. Le langage LDD impose toujours une limite de transaction. Les jobs Teradata FastLoad s'exécutent indépendamment, mais uniquement sur des tables vides.

BigQuery est également compatible avec les transactions. BigQuery permet d'assurer un contrôle de simultanéité optimiste (le premier à effectuer un commit l'emporte) avec isolation d'instantané, où une requête lit les dernières données validées avant le démarrage de la requête. Cette approche garantit le même niveau de cohérence par ligne, par mutation et entre les lignes d'une même instruction LMD, tout en évitant les interblocages. Si plusieurs instructions UPDATE sont effectuées sur la même table, BigQuery bascule vers le contrôle de simultanéité pessimiste et met en file d'attente plusieurs instructions UPDATE, en effectuant de nouvelles tentatives en cas de conflits. Les instructions LMD INSERT et les jobs de chargement peuvent s'exécuter simultanément et indépendamment pour ajouter des données aux tables.

Rollback

Teradata accepte deux modes de rollback de session, le mode session ANSI et le mode session Teradata (SET SESSION CHARACTERISTICS et SET SESSION TRANSACTION), selon le mode de rollback souhaité. En cas d'échec, le rollback de la transaction peut ne pas être possible.

BigQuery accepte l'instruction ROLLBACK TRANSACTION. Il n'y a pas d'instruction ABORT dans BigQuery.

Limites des bases de données

Vérifiez toujours les derniers quotas et les dernières limites dans la documentation publique BigQuery. Les utilisateurs ayant un volume de requêtes important peuvent demander l'augmentation de nombreux quotas en contactant l'équipe d'assistance Cloud. Le tableau suivant présente une comparaison des limites de base de données pour Teradata et BigQuery.

Limite	Teradata	BigQuery
Tables par base de données	Pas de restriction	Pas de restriction
Colonnes par table	2 048	10 000
Taille maximale des lignes	1 Mo	100 Mo
Longueur des noms de colonnes et de tables	128 caractères Unicode	16 384 caractères Unicode
Nombre de lignes par table	Illimité	Illimité
Longueur maximale des requêtes SQL	1 Mo	1 Mo (longueur maximale des requêtes GoogleSQL non résolues) 12 Mo (longueur maximale des requêtes résolues en ancien SQL et des requêtes GoogleSQL résolues) Traitement par flux : 10 Mo (taille maximale des requêtes HTTP) 10 000 (nombre maximal de lignes par requête)
Taille maximale des requêtes et des réponses	7 Mo (requête), 16 Mo (réponse)	10 Mo (requête) et 10 Go (réponse), ou presque illimitée si vous utilisez la pagination ou l'API Cloud Storage
Nombre maximal de sessions simultanées	120 par moteur d'analyse	100 requêtes simultanées (ce nombre peut être augmenté avec une réservation d'emplacement), 300 requêtes API simultanées par utilisateur
Nombre maximal de chargements (rapides) simultanés	30 (Valeur par défaut : 5)	Aucune limite de simultanéité ; les tâches sont mises en file d'attente. 100 000 tâches de chargement par projet et par jour

Guide de traduction SQL Teradata

Types de données

Mise en forme des types de données Teradata

Mise en forme des types d'horodatage et de date

Syntaxe des requêtes

Instruction SELECT

Opérateurs de comparaison

JOIN conditions

Casting et conversion des types de données

Clauses QUALIFY, ROWS

Mot clé NORMALIZE

Fonctions

Fonctions d'agrégation

Fonctions d'analyse et de fenêtrage

Fonctions de date/heure

Fonctions de chaîne

Fonctions mathématiques

Syntaxe LMD

Instruction INSERT

Instruction UPDATE

Instructions DELETE et TRUNCATE

Instruction MERGE

Variables affectées par les lignes

Syntaxe LDD

Instruction CREATE TABLE

Attributs et options de colonne

Tables temporaires

Instruction CREATE VIEW

Instruction CREATE [UNIQUE] INDEX

Indexation à des fins de performances

Indexation à des fins de cohérence (UNIQUE, PRIMARY INDEX)

Indexation pour obtenir le verrouillage

Instructions SQL procédurales

Instruction CREATE PROCEDURE

Déclaration et attribution de variables

Gestionnaires de conditions d'erreur

Déclarations et opérations de curseurs

Instructions SQL dynamiques

Instructions de flux de contrôle

Instructions SQL de métadonnées et de transactions

Instructions SQL multi-instructions et multilignes

Codes et messages d'erreur

Garanties de cohérence et isolation de transaction

Transactions

Rollback

Limites des bases de données

Instruction `SELECT`

`JOIN` conditions

Clauses `QUALIFY`, `ROWS`

Mot clé `NORMALIZE`

Instruction `INSERT`

Instruction `UPDATE`

Instructions `DELETE` et `TRUNCATE`

Instruction `MERGE`

Instruction `CREATE TABLE`

Instruction `CREATE VIEW`

Instruction `CREATE [UNIQUE] INDEX`

Instruction `CREATE PROCEDURE`