Guia de conversão de SQL do Teradata

Este documento detalha as semelhanças e diferenças de sintaxe SQL entre o Teradata e o BigQuery para ajudar você a planejar sua migração. Use a tradução SQL em lote para migrar os scripts SQL em massa ou a tradução de SQL interativo para traduzir consultas ad-hoc.

Tipos de dados

Esta seção mostra os equivalentes entre os tipos de dados no Teradata e no BigQuery.

Teradata	BigQuery	Observações
`INTEGER`	`INT64`
`SMALLINT`	`INT64`
`BYTEINT`	`INT64`
`BIGINT`	`INT64`
`DECIMAL`	`NUMERIC, DECIMAL` `BIGNUMERIC, BIGDECIMAL`	Use o `NUMERIC` (alias `DECIMAL`) do BigQuery quando a escala (dígitos após a vírgula decimal) <= 9. Use o `BIGNUMERIC` (alias `BIGDECIMAL`) do BigQuery quando a escala for > 9. Use os tipos de dados decimais parametrizados do BigQuery se precisar impor limites de dígitos personalizados ou de escala (restrições). O Teradata permite inserir valores de maior precisão ao arredondar o valor armazenado. No entanto, os cálculos continuam altamente precisos. Isso pode levar a um comportamento de arredondamento inesperado em comparação com o padrão ANSI.
`FLOAT`	`FLOAT64`
`NUMERIC`	`NUMERIC, DECIMAL` `BIGNUMERIC, BIGDECIMAL`	Use o `NUMERIC` (alias `DECIMAL`) do BigQuery quando a escala (dígitos após a vírgula decimal) <= 9. Use o `BIGNUMERIC` (alias `BIGDECIMAL`) do BigQuery quando a escala for > 9. Use os tipos de dados decimais parametrizados do BigQuery se precisar impor limites de dígitos personalizados ou de escala (restrições). O Teradata permite inserir valores de maior precisão ao arredondar o valor armazenado. No entanto, os cálculos continuam altamente precisos. Isso pode levar a um comportamento de arredondamento inesperado em comparação com o padrão ANSI.
`NUMBER`	`NUMERIC, DECIMAL` `BIGNUMERIC, BIGDECIMAL`	Use o `NUMERIC` (alias `DECIMAL`) do BigQuery quando a escala (dígitos após a vírgula decimal) <= 9. Use o `BIGNUMERIC` (alias `BIGDECIMAL`) do BigQuery quando a escala for > 9. Use os tipos de dados decimais parametrizados do BigQuery se precisar impor limites de dígitos personalizados ou de escala (restrições). O Teradata permite inserir valores de maior precisão ao arredondar o valor armazenado. No entanto, os cálculos continuam altamente precisos. Isso pode levar a um comportamento de arredondamento inesperado em comparação com o padrão ANSI.
`REAL`	`FLOAT64`
`CHAR/CHARACTER`	`STRING`	Use os tipos de dado `STRING` parametrizados do BigQuery se você precisar aplicar um comprimento máximo de caracteres.
`VARCHAR`	`STRING`	Use os tipos de dado `STRING` parametrizados do BigQuery se você precisar aplicar um comprimento máximo de caracteres.
`CLOB`	`STRING`
`JSON`	`JSON`
`BLOB`	`BYTES`
`BYTE`	`BYTES`
`VARBYTE`	`BYTES`
`DATE`	`DATE`	O BigQuery não oferece suporte à formatação personalizada semelhante ao suporte que o Teradata oferece com DataForm no SDF.
`TIME`	`TIME`
`TIME WITH TIME ZONE`	`TIME`	O Teradata armazena o tipo de dados `TIME` no UTC e permite que você passe um deslocamento do UTC usando a sintaxe `WITH TIME ZONE`.O tipo de dados `TIME` no BigQuery representa um horário independente de qualquer data ou fuso horário.
`TIMESTAMP`	`TIMESTAMP`	Os tipos de dados `TIMESTAMP` do Teradata e do BigQuery têm precisão de microssegundos. No entanto, o Teradata é compatível com segundos intercalares, mas o BigQuery não. Os tipos de dados do Teradata e do BigQuery geralmente são associados a um fuso horário UTC. Veja os detalhes aqui.
`TIMESTAMP WITH TIME ZONE`	`TIMESTAMP`	O `TIMESTAMP` do Teradata pode ser definido como um fuso horário diferente para todo o sistema, por usuário ou coluna (usando `WITH TIME ZONE`). O tipo `TIMESTAMP` do BigQuery define UTC como padrão se você não especifica explicitamente um fuso horário. Verifique se você exportou informações de fuso horário corretamente para que o BigQuery possa convertê-las na importação. Não concatene um valor `DATE` e `TIME` sem informações de fuso horário. Verifique se você converteu as informações de fuso horário em UTC antes da exportação. O BigQuery tem `DATETIME` para uma abstração dentro da hora legal, que não mostra um fuso horário quando ele é gerado, e `TIMESTAMP`, que é um ponto preciso no tempo que sempre mostra o fuso horário UTC.
`ARRAY`	`ARRAY`
`MULTI-DIMENSIONAL ARRAY`	`ARRAY`	No BigQuery, use uma matriz de structs. Cada struct contém um campo do tipo `ARRAY`. Para detalhes, consulte a documentação do 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)` precisa ser convertido em duas colunas `DATE` contendo a data de início e a data de término para que elas possam ser usadas com funções de janela.
`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`

Para mais informações sobre a transmissão de tipos, consulte a próxima seção.

Formatação de tipo do Teradata

O Teradata SQL usa um conjunto de formatos padrão para exibir expressões e dados de coluna e para conversões entre tipos de dados. Por exemplo, um tipo de dados PERIOD(DATE) no modo INTEGERDATE é formatado como YY/MM/DD por padrão. Sugerimos usar o modo ANSIDATE sempre que possível para garantir a conformidade com o SQL ANSI e usar essa chance para limpar os formatos legados.

O Teradata permite a aplicação automática de formatos personalizados usando a cláusula FORMAT, sem alterar o armazenamento subjacente, como um atributo de tipo de dados quando você cria uma tabela usando DDL ou em uma expressão derivada. Por exemplo, uma especificação FORMAT 9.99 arredonda qualquer valor FLOAT para dois dígitos. No BigQuery, essa funcionalidade precisa ser convertida usando a função ROUND().

Essa funcionalidade requer o tratamento de casos extremos complexos. Por exemplo, quando a cláusula FORMAT é aplicada a uma coluna NUMERIC, é preciso considerar as regras especiais de arredondamento e formatação da conta (em inglês). Uma cláusula FORMAT pode ser usada para converter implicitamente um valor de época INTEGER para um formato DATE. Ou uma especificação FORMAT X(6) em uma coluna VARCHAR truncará o valor da coluna e, portanto, você precisará convertê-lo em uma função SUBSTR(). Esse comportamento não é compatível com ANSI SQL. Portanto, sugerimos não migrar formatos de coluna para o BigQuery.

Se os formatos de coluna forem absolutamente necessários, use Visualizações ou funções definidas pelo usuário (UDF, na sigla em inglês).

Para informações sobre os formatos padrão que o Teradata SQL usa para cada tipo de dados, consulte a documentação em inglês Formatação padrão do Teradata.

Formatação de carimbo de data/hora e tipo de data

A tabela a seguir resume as diferenças nos elementos de formatação de carimbo de data/hora e de data entre o Teradata SQL e o GoogleSQL.

Formato Teradata	Descrição do Teradata	BigQuery
`CURRENT_TIMESTAMP CURRENT_TIME`	As informações de `TIME` e `TIMESTAMP` no Teradata podem ter dados de fuso horário diferentes, o que é definido usando `WITH TIME ZONE`.	Se possível, use `CURRENT_TIMESTAMP()`, que tem o formato ISO. No entanto, o formato de saída sempre mostra o fuso horário UTC. Internamente, o BigQuery não tem um fuso horário. Observe os seguintes detalhes sobre as diferenças no formato ISO. `DATETIME` é formatado com base nas convenções do canal de saída. Na ferramenta de linha de comando do BigQuery e no console do BigQuery, ele é formatado usando um separador `T` de acordo com a RFC 3339. No entanto, em Python e Java JDBC, um espaço é usado como separador. Se você quiser usar um formato explícito, use `FORMAT_DATETIME()`, que transforma uma transmissão explícita em uma string. Por exemplo, a expressão a seguir sempre retorna um separador de espaço: `CAST(CURRENT_DATETIME() AS STRING)` O Teradata é compatível com uma palavra-chave `DEFAULT` em colunas `TIME` para definir a hora atual (carimbo de data/hora). Isso não é usado no BigQuery.
`CURRENT_DATE`	As datas são armazenadas no Teradata como valores `INT64` usando a seguinte fórmula: `(YEAR - 1900) * 10000 + (MONTH * 100) + DAY` As datas podem ser formatadas como números inteiros.	O BigQuery tem um formato `DATE` separado que sempre retorna uma data no formato ISO 8601. `DATE_FROM_UNIX_DATE` não pode ser usado porque é baseado em 1970. O Teradata aceita uma palavra-chave `DEFAULT` nas colunas `DATE` para definir a data atual. Isso não é usado no BigQuery.
`CURRENT_DATE-3`	Os valores de data são representados como números inteiros. O Teradata é compatível com operadores aritméticos para tipos de data.	Para tipos de data, use `DATE_ADD()` ou `DATE_SUB()`. O BigQuery usa operadores aritméticos para tipos de dados: `INT64`, `NUMERIC` e `FLOAT64`.
`SYS_CALENDAR.CALENDAR`	O Teradata fornece uma visualização para operações de agenda que vão além de operações de número inteiro.	Não usado no BigQuery.
`SET SESSION DATEFORM=ANSIDATE`	Defina o formato de data da sessão ou do sistema como ANSI (ISO 8601).	O BigQuery sempre usa o ISO 8601. Portanto, converta datas e horários do Teradata.

Sintaxe das consultas

Nesta seção, abordamos as diferenças na sintaxe de consulta entre o Teradata e o BigQuery.

Instrução `SELECT`

A maioria das instruções SELECT (em inglês) do Teradata é compatível com o BigQuery. A tabela a seguir contém uma lista de pequenas diferenças.

Teradata		BigQuery
`SEL`		Converta para `SELECT`. O BigQuery não usa a abreviação `SEL`.
`SELECT (subquery) AS flag, CASE WHEN flag = 1 THEN ...`		No BigQuery, as colunas não podem referenciar a saída de outras colunas definidas na mesma lista de seleção. Prefira mover uma subconsulta para uma cláusula `WITH`. `WITH flags AS ( subquery ), SELECT CASE WHEN flags.flag = 1 THEN ...`
`SELECT * FROM table WHERE A LIKE ANY ('string1', 'string2')`		O BigQuery não usa o predicado de lógica `ANY`. A mesma funcionalidade pode ser alcançada usando vários operadores `OR`: `SELECT * FROM table WHERE col LIKE 'string1' OR col LIKE 'string2'` Nesse caso, a comparação de strings também é diferenciada. Consulte Operadores de comparação.
`SELECT TOP 10 * FROM table`		O BigQuery usa `LIMIT` no final de uma consulta em vez de `TOP n` após a palavra-chave `SELECT`.

Operadores de comparação

A tabela a seguir mostra os operadores de comparação específicos do Teradata e que precisam ser convertidos em operadores compatíveis com ANSI SQL:2011 usados no BigQuery.

Para informações sobre operadores no BigQuery, consulte a seção Operadores da documentação do BigQuery.

Teradata	BigQuery	Observações
`exp EQ exp2` `exp IN (exp2, exp3)`	`exp = exp2` `exp IN (exp2, exp3)` Para manter a semântica não ANSI para `NOT CASESPECIFIC`, use `RTRIM(UPPER(exp)) = RTRIM(UPPER(exp2))`	Ao comparar strings por igualdade, o Teradata pode ignorar espaços em branco posteriores, enquanto o BigQuery as considera parte da string. Por exemplo, `'xyz'=' xyz'` é `TRUE` no Teradata, mas `FALSE` no BigQuery. O Teradata também fornece um atributo de coluna `NOT CASESPECIFIC` que instrui o Teradata a ignorar maiúsculas e minúsculas ao comparar duas strings. O BigQuery sempre especifica maiúsculas e minúsculas ao comparar strings. Por exemplo, `'xYz' = 'xyz'` é `TRUE` no Teradata, mas `FALSE` no 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` condição

O BigQuery e o Teradata são compatíveis com as mesmas condições JOIN, ON e USING. A tabela a seguir contém uma lista de pequenas diferenças.

Teradata	BigQuery	Observações
`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`	O BigQuery aceita cláusulas de desigualdade `JOIN` para todas as junções internas ou se pelo menos uma condição de igualdade for fornecida (=). Mas não apenas uma condição de desigualdade (= and <) em um `OUTER JOIN`. Essas construções às vezes são usadas para consultar intervalos de data ou inteiros. O BigQuery impede que os usuários criem grandes junções cruzadas.
`FROM A, B ON A.id = B.id`	`FROM A JOIN B ON A.id = B.id`	O uso de uma vírgula entre tabelas no Teradata é igual a um `INNER JOIN`, enquanto no BigQuery é igual a um `CROSS JOIN` (produto cartesiano). Como a vírgula no SQL legado do BigQuery é tratada como `UNION`, recomendamos tornar a operação explícita para evitar confusão.
`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))`	Não há diferença para funções escalares (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`	O BigQuery impede que os usuários usem subconsultas, subconsultas correlacionadas ou agregações em predicados de junção. Isso permite que o BigQuery coloque as consultas em paralelo.

Conversão e transmissão de tipo

O BigQuery tem menos tipos de dados, porém mais amplos que o Teradata, o que exige que o BigQuery seja mais rigoroso na transmissão.

Teradata	BigQuery	Observações
`exp EQ exp2` `exp IN (exp2, exp3)`	`exp = exp2` `exp IN (exp2, exp3)` Para manter a semântica não ANSI para `NOT CASESPECIFIC`, use `RTRIM(UPPER(exp)) = RTRIM(UPPER(exp2))`	Ao comparar strings por igualdade, o Teradata pode ignorar espaços em branco posteriores, enquanto o BigQuery as considera parte da string. Por exemplo, `'xyz'=' xyz'` é `TRUE` no Teradata, mas `FALSE` no BigQuery. O Teradata também fornece um atributo de coluna `NOT CASESPECIFIC` que instrui o Teradata a ignorar maiúsculas e minúsculas ao comparar duas strings. O BigQuery sempre especifica maiúsculas e minúsculas ao comparar strings. Por exemplo, `'xYz' = 'xyz'` é `TRUE` no Teradata, mas `FALSE` no BigQuery.
`CAST(long_varchar_column AS CHAR(6))`	`LPAD(long_varchar_column, 6)`	A transmissão de uma coluna de caracteres no Teradata é usada às vezes como uma maneira não padrão e não ideal para criar uma substring preenchida.
`CAST(92617 AS TIME) 92617 (FORMAT '99:99:99')`	`PARSE_TIME("%k%M%S", CAST(92617 AS STRING))`	O Teradata realiza muitas conversões de tipo implícitas (em inglês) e arredondamentos do que o BigQuery, que geralmente é mais rigoroso e aplica padrões ANSI. (Este exemplo retorna 09:26:17)
`CAST(48.5 (FORMAT 'zz') AS FLOAT)`	`CAST(SUBSTR(CAST(48.5 AS STRING), 0, 2) AS FLOAT64)`	Os tipos de dados numéricos e de ponto flutuante podem exigir regras de arredondamento (em inglês) especiais, quando aplicados com formatos como moedas. (Este exemplo retorna 48)

Consulte também Operadores de comparação e formatos de coluna. As comparações e a formatação das colunas podem se comportar como os tipos de conversão.

Cláusulas `QUALIFY` e `ROWS`

A cláusula QUALIFY no Teradata permite que você filtre os resultados para funções de janela (em inglês). Como alternativa, uma frase ROWS (em inglês) pode ser usada para a mesma tarefa. Isso funciona de maneira semelhante a uma condição HAVING para uma cláusula GROUP, limitando a saída do que no BigQuery é chamado de funções de janela.

Teradata BigQuery

SELECT col1, col2 FROM table QUALIFY ROW_NUMBER() OVER (PARTITION BY col1 ORDER BY col2) = 1; A cláusula QUALIFY do Teradata com uma função de janela como ROW_NUMBER(), SUM() e COUNT() e com OVER PARTITION BY é expressa no BigQuery como uma cláusula WHERE em uma subconsulta que contém um valor de análise.

Como usar o ROW_NUMBER():

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

Como usar o ARRAY_AGG, que é compatível com partições maiores:

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);

No BigQuery, RANGE e ROWS podem ser usados na cláusula do frame da janela. No entanto, as cláusulas de janela só podem ser usadas com funções de janela como AVG(), não com funções de numeração como ROW_NUMBER().

Teradata	BigQuery
`SELECT col1, col2 FROM table QUALIFY ROW_NUMBER() OVER (PARTITION BY col1 ORDER BY col2) = 1;`	A cláusula `QUALIFY` do Teradata com uma função de janela como `ROW_NUMBER()`, `SUM()` e `COUNT()` e com `OVER PARTITION BY` é expressa no BigQuery como uma cláusula `WHERE` em uma subconsulta que contém um valor de análise. Como usar o `ROW_NUMBER()`: `SELECT col1, col2 FROM ( SELECT col1, col2, ROW_NUMBER() OVER (PARTITION BY col1 ORDER BY col2) RN FROM table ) WHERE RN = 1;` Como usar o `ARRAY_AGG`, que é compatível com partições maiores: `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);` No BigQuery, `RANGE` e `ROWS` podem ser usados na cláusula do frame da janela. No entanto, as cláusulas de janela só podem ser usadas com funções de janela como `AVG()`, não com funções de numeração como `ROW_NUMBER()`.

Palavra-chave `NORMALIZE`

O Teradata fornece a palavra-chave NORMALIZE para cláusulas SELECT para aglutinar períodos ou intervalos sobrepostos em um período ou intervalo que englobe todos os valores de períodos individuais.

O BigQuery não é compatível com o tipo PERIOD. Portanto, qualquer coluna com tipo PERIOD no Teradata precisa ser inserido no BigQuery como dois campos DATE ou DATETIME separados que correspondem ao início e ao fim do período.

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;

Funções

As seções a seguir listam mapeamentos entre funções do Teradata e equivalentes do BigQuery.

Funções de agregação

A tabela a seguir correlaciona funções comuns de agregação, agregação estatística e agregação aproximada do Teradata com os equivalentes do BigQuery. O BigQuery oferece as seguintes funções extras de agregação:

Teradata	BigQuery
`AVG`	`AVG`
`BITAND`	`BIT_AND`
`BITNOT`	Lógica binária não operadora (`~`)
`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`	Função personalizada definida pelo usuário.
`STDDEV_POP`	`STDDEV_POP`
`STDDEV_SAMP`	`STDDEV_SAMP, STDDEV`
`SUM`	`SUM`
`VAR_POP`	`VAR_POP`
`VAR_SAMP`	`VAR_SAMP, VARIANCE`

Funções de análise e de janela

A tabela a seguir correlaciona funções comuns de análise e agregadas do Teradata com os equivalentes da função de janela do BigQuery. O BigQuery oferece as seguintes funções adicionais:

Teradata	BigQuery
`ARRAY_AGG`	`ARRAY_AGG`
`ARRAY_CONCAT, (\|\| operator)`	`ARRAY_CONCAT_AGG, (\|\| operator)`
`BITAND`	`BIT_AND`
`BITNOT`	Lógica binária não operadora (`~`)
`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`

Funções de data/hora

A tabela a seguir correlaciona funções comuns de data/hora do Teradata com os equivalentes do BigQuery. O BigQuery oferece as seguintes funções extras de data/hora:

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` Observação: esta função é compatível com as expressões de entrada `DATE` e `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`

Funções de string

A tabela a seguir correlaciona as funções comuns de string do Teradata com os equivalentes do BigQuery. O BigQuery oferece as seguintes funções extras de string:

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`	Função personalizada definida pelo usuário.
`CSVLD`	Função personalizada definida pelo usuário.
`FORMAT`	`FORMAT`
`INDEX`	`STRPOS(string, substring)`
`INITCAP`	`INITCAP`
`INSTR`	Função personalizada definida pelo usuário.
`LEFT`	`SUBSTR(source_string, 1, length)`
`LENGTH`	`LENGTH`
`LOWER`	`LOWER`
`LPAD`	`LPAD`
`LTRIM`	`LTRIM`
`NGRAM`	Função personalizada definida pelo usuário.
`NVP`	Função personalizada definida pelo usuário.
`OREPLACE`	`REPLACE`
`OTRANSLATE`	Função personalizada definida pelo usuário.
`POSITION`	`STRPOS(string, substring)`
`REGEXP_INSTR`	`STRPOS(source_string, REGEXP_EXTRACT(source_string, regexp_string))` Observação: retorna a primeira ocorrência.
`REGEXP_REPLACE`	`REGEXP_REPLACE`
`REGEXP_SIMILAR`	`IF(REGEXP_CONTAINS,1,0)`
`REGEXP_SUBSTR`	`REGEXP_EXTRACT, REGEXP_EXTRACT_ALL`
`REGEXP_SPLIT_TO_TABLE`	Função personalizada definida pelo usuário.
`REVERSE`	`REVERSE`
`RIGHT`	`SUBSTR(source_string, -1, length)`
`RPAD`	`RPAD`
`RTRIM`	`RTRIM`
`STRTOK` Observação: cada caractere no argumento da string do delimitador é considerado um caractere delimitador separado. O delimitador padrão é um caractere de espaço.	`SPLIT(instring, delimiter)[ORDINAL(tokennum)]` Observação: todo o argumento da string do delimitador é usado como um único delimitador. O delimitador padrão é uma vírgula.
`STRTOK_SPLIT_TO_TABLE`	Função personalizada definida pelo usuário
`SUBSTRING`, `SUBSTR`	`SUBSTR`
`TRIM`	`TRIM`
`UPPER`	`UPPER`

Funções matemáticas

A tabela a seguir correlaciona as funções matemáticas do Teradata com os equivalentes do BigQuery. O BigQuery oferece as seguintes funções matemáticas extras:

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` (operador `%`)	`MOD`
`NULLIFZERO`	`NULLIF(expression, 0)`
`POWER` (operador `**`)	`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)`

Sintaxe DML

Esta seção aborda as diferenças na sintaxe da linguagem de gerenciamento de dados entre o Teradata e o BigQuery.

Instrução `INSERT`

A maioria das instruções INSERT do Teradata é compatível com o BigQuery. A tabela a seguir mostra as exceções.

Os scripts DML no BigQuery têm semânticas de consistência ligeiramente diferentes das instruções equivalentes no Teradata. Para uma visão geral do isolamento de snapshot e do processamento de sessões e transações, consulte a seção CREATE INDEX em outras partes deste documento.

Teradata BigQuery

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

O Teradata oferece uma palavra-chave DEFAULT para colunas não anuláveis.

Observação: no BigQuery, a omissão de nomes de coluna na instrução INSERT funcionará somente se os valores de todas as colunas na tabela de destino forem incluídos em ordem crescente com base nas posições ordinais.

Teradata	BigQuery
`INSERT INTO table VALUES (...);`	`INSERT INTO table (...) VALUES (...);` O Teradata oferece uma palavra-chave `DEFAULT` para colunas não anuláveis. Observação: no BigQuery, a omissão de nomes de coluna na instrução `INSERT` funcionará somente se os valores de todas as colunas na tabela de destino forem incluídos em ordem crescente com base nas posições ordinais.
`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);` O Teradata tem um conceito de solicitação de várias instruções (MSR, na sigla em inglês), que envia várias instruções `INSERT` por vez (link em inglês). No BigQuery, isso não é recomendado devido ao limite de transação implícito entre as instruções. Use vários valores `INSERT`. O BigQuery permite instruções `INSERT` simultâneas, mas pode enfileirar `UPDATE`. Para melhorar o desempenho, considere as seguintes abordagens: Combine várias linhas em uma única instrução `INSERT`, em vez de uma linha por operação `INSERT`. Combine várias instruções DML (incluindo `INSERT`) usando uma instrução `MERGE`. Use `CREATE TABLE ... AS SELECT` para criar e preencher novas tabelas em vez de `UPDATE` ou `DELETE`, em particular ao consultar campos particionados ou reverter ou restaurar.


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);

O Teradata tem um conceito de solicitação de várias instruções (MSR, na sigla em inglês), que envia várias instruções INSERT por vez (link em inglês). No BigQuery, isso não é recomendado devido ao limite de transação implícito entre as instruções. Use vários valores INSERT.

O BigQuery permite instruções INSERT simultâneas, mas pode enfileirar UPDATE. Para melhorar o desempenho, considere as seguintes abordagens:

Combine várias linhas em uma única instrução INSERT, em vez de uma linha por operação INSERT.
Combine várias instruções DML (incluindo INSERT) usando uma instrução MERGE.
Use CREATE TABLE ... AS SELECT para criar e preencher novas tabelas em vez de UPDATE ou DELETE, em particular ao consultar campos particionados ou reverter ou restaurar.

Instrução `UPDATE`

A maioria das instruções UPDATE do Teradata (em inglês) é compatível com o BigQuery, exceto os seguintes itens:

Quando você usa uma cláusula FROM, a ordem das cláusulas FROM e SET é revertida no Teradata e no BigQuery.
No GoogleSQL, cada instrução UPDATE precisa incluir a palavra-chave WHERE, seguida por uma condição. Para atualizar todas as linhas da tabela, use WHERE true.

Como prática recomendada, você precisa agrupar várias mutações DML em vez de instruções UPDATE e INSERT únicas. Os scripts DML no BigQuery têm uma semântica de consistência ligeiramente diferente das declarações equivalentes no Teradata. Para uma visão geral do isolamento de snapshot e do processamento de sessões e transações, consulte a seção CREATE INDEX em outras partes deste documento.

A tabela a seguir mostra instruções UPDATE do Teradata e instruções do BigQuery que realizam as mesmas tarefas.

Para mais informações sobre UPDATE no BigQuery, consulte os exemplos de UPDATE do BigQuery na documentação do DML.

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;`

Declarações `DELETE` e `TRUNCATE`.

As instruções DELETE e TRUNCATE são maneiras de remover linhas de uma tabela sem afetar o esquema ou os índices dela. TRUNCATE não é usado no Teradata nem no BigQuery. No entanto, é possível usar DELETE para ter o mesmo efeito.

No BigQuery, a instrução DELETE precisa ter uma cláusula WHERE. Para excluir todas as linhas da tabela (truncate), use WHERE true. Para acelerar as operações de truncamento de tabelas muito grandes, recomendamos usar a instrução CREATE OR REPLACE TABLE ... AS SELECT, usando um LIMIT 0 na mesma tabela para que substitua a si mesmo. No entanto, adicione manualmente as informações de particionamento e clustering.

Os gravadores do Teradata foram excluídos posteriormente. Isso significa que as operações DELETE são inicialmente mais rápidas do que no BigQuery, mas exigem recursos mais tarde, especialmente as operações DELETE em grande escala que afetam a maioria de uma tabela. Para usar uma abordagem semelhante no BigQuery, sugerimos reduzir o número de operações DELETE, como copiar as linhas que não serão excluídas em uma nova tabela. Como alternativa, é possível remover partições inteiras. Ambas as opções foram projetadas para serem operações mais rápidas do que mutações DML atômicas.

Para mais informações sobre DELETE no BigQuery, consulte os exemplos de DELETE na documentação do DML.

Teradata	BigQuery
`BEGIN TRANSACTION; LOCKING TABLE table_A FOR EXCLUSIVE; DELETE FROM table_A; INSERT INTO table_A SELECT * FROM table_B; END TRANSACTION;`	Substituir o conteúdo de uma tabela pela saída da consulta é equivalente a uma transação. É possível fazer isso com uma operação de consulta ou de cópia. Como usar uma operação de consulta: `bq query --replace --destination_table table_A 'SELECT * FROM table_B';` Como usar uma operação de cópia: `bq cp -f table_A table_B`
`DELETE database.table ALL;`	`DELETE FROM table WHERE TRUE;` Para tabelas muito grandes, uma maneira mais rápida: `CREATE OR REPLACE table AS SELECT * FROM table LIMIT 0;`

Instrução `MERGE`

A instrução MERGE pode combinar operações INSERT, UPDATE e DELETE em uma única instrução "upsert" e realizar as operações de maneira atômica. A operação MERGE precisa corresponder no máximo a uma linha de origem para cada linha de destino. O BigQuery e o Teradata seguem a sintaxe ANSI.

A operação MERGE do Teradata está limitada a correspondência de chaves primárias em um processador do módulo de acesso, ou AMP, na sigla em inglês (link em inglês). Por outro lado, o BigQuery não tem limite de tamanho ou coluna para operações MERGE. Portanto, usar MERGE é uma otimização útil. No entanto, se MERGE for basicamente uma exclusão grande, consulte otimizações para DELETE em outro lugar neste documento.

Os scripts DML no BigQuery têm uma semântica de consistência ligeiramente diferente das declarações equivalentes no Teradata. Por exemplo, as tabelas SET do Teradata no modo de sessão podem ignorar cópias (em inglês) durante uma operação MERGE. Para uma visão geral sobre como lidar com tabelas MULTISET e SET, isolamento de snapshot e processamento de sessões e transações, consulte a seção CREATE INDEX em outro lugar deste documento.

Variáveis afetadas por linhas

No Teradata, a variável ACTIVITY_COUNT (em inglês) é uma extensão ANSI SQL do Teradata preenchida com o número de linhas afetadas por uma instrução DML.

A variável de sistema @@row_count no recurso de script tem uma funcionalidade semelhante. No BigQuery, seria mais comum verificar o valor de retorno numDmlAffectedRows nos registros de auditoria ou nas visualizações INFORMATION_SCHEMA.

Sintaxe DDL

Nesta seção, abordamos as diferenças na sintaxe da linguagem de definição de dados entre o Teradata e o BigQuery.

Instrução `CREATE TABLE`

A maioria das instruções CREATE TABLE (em inglês) do Teradata são compatíveis com o BigQuery, exceto pelos seguintes elementos de sintaxe, que não são usados no BigQuery:

MULTISET. Consulte a seção CREATE INDEX.
VOLATILE. Consulte a seção Tabelas temporárias.
[NO] FALLBACK. Consulte a seção Reverter.
[NO] BEFORE JOURNAL, [NO] AFTER JOURNAL
CHECKSUM = DEFAULT | val
DEFAULT MERGEBLOCKRATIO
PRIMARY INDEX (col, ...). Consulte a seção CREATE INDEX.
UNIQUE PRIMARY INDEX. Consulte a seção CREATE INDEX.
CONSTRAINT
DEFAULT
IDENTITY

Para mais informações sobre CREATE TABLE no BigQuery, consulte os exemplos de CREATE do BigQuery na documentação do DML.

Atributos e opções de coluna

As seguintes especificações de coluna para a instrução CREATE TABLE não são usadas no BigQuery:

FORMAT 'format'. Consulte a seção sobre formatação de tipos do Teradata.
CHARACTER SET name. O BigQuery sempre usa a codificação UTF-8.
[NOT] CASESPECIFIC
COMPRESS val | (val, ...)

O Teradata estende o padrão ANSI com uma opção de coluna TITLE (em inglês). Esse recurso pode ser implementado de maneira semelhante no BigQuery usando a descrição da coluna, conforme mostrado na tabela a seguir. Essa opção não está disponível para visualizações.

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

Tabelas temporárias

O Teradata é compatível com tabelas voláteis (em inglês), que costumam ser usadas para armazenar resultados intermediários em scripts. Há várias maneiras de conseguir algo semelhante a tabelas voláteis no BigQuery:

CREATE TEMPORARY TABLE pode ser usado em Scripts e é válido durante a vida útil do script. Se a tabela tiver que existir além de um script, use as outras opções nesta lista.
Tempo de vida (TTL, na sigla em inglês) do conjunto de dados: crie um conjunto de dados que tenha um curto tempo de vida, por exemplo, uma hora, para que as tabelas criadas no conjunto de dados sejam efetivamente temporárias, já que não permanecerão por mais tempo do que o tempo de vida do conjunto de dados. É possível prefixar todos os nomes de tabela neste conjunto de dados com temp para indicar claramente que as tabelas são temporárias.
Tempo de vida (TTL, na sigla em inglês) da tabela: crie uma tabela que tenha um curto tempo de vida específico usando instruções DDL semelhantes às seguintes:
```
CREATE TABLE temp.name (col1, col2, ...)
OPTIONS(expiration_timestamp=TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL 1 HOUR));
```
Cláusula WITH: se uma tabela temporária for necessária apenas dentro do mesmo bloco, use um resultado temporário usando uma instrução ou subconsulta WITH. Essa é a opção mais eficiente.

Um padrão usado com frequência em scripts do Teradata (BTEQ) é criar uma tabela permanente, inserir um valor nela, usá-la como uma tabela temporária em instruções contínuas e depois excluir ou truncar a tabela (link em inglês). Na verdade, ele usa a tabela como uma variável constante (um parâmetro). Essa abordagem não é eficiente no BigQuery, mas recomendamos o uso de variáveis reais no Script ou o uso de CREATE OR REPLACE com a sintaxe de consulta AS SELECT para criar uma tabela que já tenha valores.

Instrução `CREATE VIEW`

A tabela a seguir mostra equivalentes entre o Teradata e o BigQuery para a instrução CREATE VIEW. As cláusulas para bloqueio de tabelas, como LOCKING ROW FOR ACCESS (em inglês), não são necessárias no BigQuery.

Teradata	BigQuery	Observações
`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 ...`
Não compatível	`CREATE VIEW IF NOT EXISTS OPTIONS(view_option_list) AS SELECT ...`	Cria uma nova visualização somente se ela não existir no conjunto de dados especificado.

Instrução `CREATE [UNIQUE] INDEX`

O Teradata requer índices para todas as tabelas e exige soluções alternativas, como tabelas MULTISET e NoPI (links em inglês), para trabalhar com dados que não sejam exclusivos nem indexados.

O BigQuery não requer índices. Nesta seção, descrevemos abordagens no BigQuery para saber como criar funcionalidades semelhantes à maneira como os índices são usados no Teradata, onde há uma necessidade real de lógica de negócios.

Indexação de desempenho

Por ser um banco de dados orientado a colunas com otimização de consulta e armazenamento, o BigQuery não precisa de índices explícitos. O BigQuery oferece funcionalidades como particionamento e clustering, bem como campos aninhados, que podem aumentar a eficiência e o desempenho da consulta otimizando como os dados são armazenados.

O Teradata não é compatível com visualizações materializadas. No entanto, ele oferece índices de mesclagem (em inglês) usando a instrução CREATE JOIN INDEX, que basicamente materializa os dados necessários para uma mesclagem. O BigQuery não precisa de índices materializados para acelerar o desempenho, assim como não precisa de espaço dedicado do spool para junções.

Para outros casos de otimização, é possível usar visualizações materializadas.

Indexação de consistência (UNIQUE, PRIMARY INDEX)

No Teradata, um índice exclusivo pode ser usado para evitar linhas com chaves não exclusivas em uma tabela. Se um processo tentar inserir ou atualizar dados com um valor que já está no índice, a operação falhará com uma violação de índice (tabelas MULTISET) ou ignorará silenciosamente (SET).

Como o BigQuery não fornece índices explícitos, uma instrução MERGE pode ser usada para inserir somente registros exclusivos em uma tabela de destino de uma tabela de preparo e descartando registros duplicados. No entanto, não há como impedir que um usuário com permissões para edição insira um registro duplicado porque o BigQuery nunca pode ser bloqueado durante as operações INSERT. Para gerar um erro para registros duplicados no BigQuery, use uma instrução MERGE de uma tabela de preparo, conforme mostrado no exemplo a seguir.

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());

Com mais frequência, os usuários preferem remover cópias duplicadas de maneira independente para encontrar erros nos sistemas posteriores.
O BigQuery não é compatível com as colunas DEFAULT e IDENTITY (sequências).

Indexação para conseguir o bloqueio

O Teradata fornece recursos no processador de módulo de acesso (AMP, na sigla em inglês). As consultas podem consumir recursos totalmente AMP, de um AMP ou AMP de grupos (link em inglês). As instruções DDL são totalmente AMP e, portanto, semelhantes a um bloqueio DDL global. O BigQuery não tem um mecanismo de bloqueio como esse e pode executar consultas simultâneas e instruções INSERT até sua cota. Somente instruções DML UPDATE simultâneas têm certas implicações de simultaneidade: as operações UPDATE na mesma partição são colocadas na fila para garantir o isolamento do snapshot. Portanto, não é necessário um bloqueio para prevenir as leituras fantasma ou perder atualizações.

Devido a essas diferenças, os seguintes elementos do Teradata não são usados no BigQuery:

ON COMMIT DELETE ROWS;
ON COMMIT PRESERVE ROWS;

Instruções SQL procedurais

Nesta seção, descrevemos como converter instruções SQL processuais usadas em procedimentos, funções e gatilhos armazenados do Teradata para scripts, procedimentos ou funções definidas pelo usuário (UDFs, na sigla em inglês) do BigQuery. Todas essas opções estão disponíveis para que os administradores do sistema possam verificar por meio das visualizações INFORMATION_SCHEMA.

Instrução `CREATE PROCEDURE`

Os procedimentos armazenados são aceitos como parte dos Scripts do BigQuery.

No BigQuery, os scripts se referem a qualquer uso de instruções de controle, enquanto os procedimentos são chamados de scripts (com argumentos, se necessário), que podem ser chamados de outros scripts e armazenados permanentemente, se necessário. Uma função definida pelo usuário (UDF, na sigla em inglês) também pode ser escrita em JavaScript.

Teradata	BigQuery
`CREATE PROCEDURE`	`CREATE PROCEDURE` quando um nome for necessário. Caso contrário, use in-line com `BEGIN` ou em uma única linha com `CREATE TEMP FUNCTION`.
`REPLACE PROCEDURE`	`CREATE OR REPLACE PROCEDURE`
`CALL`	`CALL`

As seções a seguir descrevem maneiras de converter instruções processuais atuais do Teradata em instruções de script do BigQuery que têm funcionalidade semelhante.

Declaração e atribuição de variáveis

As variáveis do BigQuery são válidas durante o ciclo de vida do script.

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

Gerenciadores de condição de erro

O Teradata usa gerenciadores em códigos de status em procedimentos de controle de erros. No BigQuery, o tratamento de erros é um recurso principal do fluxo de controle principal. Ele é semelhante ao fornecido por outros idiomas com blocos 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;`	Os gerenciadores de exceções acionados em determinadas condições de erro não são usados pelo BigQuery. Recomendamos o uso de instruções `ASSERT` em que as condições de saída são utilizadas para verificações prévias ou depuração, porque isso está em compliance com o ANSI SQL:2011.

A variável SQLSTATE (em inglês) na Teradata é semelhante à variável de sistema @@error no BigQuery. No BigQuery, é mais comum investigar erros usando a geração de registros de auditoria ou as visualizações INFORMATION_SCHEMA.

Declarações e operações do cursor

Como o BigQuery não é compatível com cursores ou sessões, as seguintes instruções não são usadas no BigQuery:

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;

Instruções SQL dinâmicas

O recurso de criação de script no BigQuery é compatível com instruções SQL dinâmicas, como as mostradas na tabela a seguir.

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

As seguintes instruções SQL dinâmicas não são usadas no BigQuery:

PREPARE stmt_id FROM sql_str;

Instruções de fluxo de controle

O recurso de script no BigQuery é compatível com instruções de fluxo de controle como as mostradas na tabela a seguir.

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;`	Construções de blocos no estilo GOTO não são usadas no BigQuery. É recomendável gravá-las novamente como funções definidas pelo usuário (UDFs) ou utilizar instruções `ASSERT` em que as construções são usadas para lidar com de erros.
`REPEAT stmts UNTIL condition END REPEAT;`	`WHILE condition DO stmts END WHILE`
`LEAVE outer_proc_label;`	`LEAVE` não é usado para blocos no estilo GOTO, ele é usado como sinônimo de `BREAK` para deixar um loop `WHILE`.
`LEAVE label;`	`LEAVE` não é usado para blocos no estilo GOTO, ele é usado como sinônimo de `BREAK` para deixar um loop `WHILE`.
`WITH RECURSIVE temp_table AS ( ... );`	Consultas recorrentes, também conhecidas como expressões recorrentes de tabela comum (CTE, na sigla em inglês), não são usadas no BigQuery. Elas podem ser gravadas novamente usando matrizes de `UNION ALL`.

As instruções de fluxo de controle a seguir não são usadas no BigQuery porque o BigQuery não usa cursores ou sessões:

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

Instruções SQL de metadados e transações

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` A mesma consulta é válida para receber informações de coluna para visualizações. Para mais informações, consulte a Visualização de colunas no `INFORMATION_SCHEMA` do BigQuery.
`SELECT * FROM dbc.tables WHERE tablekind = 'T';` (visualização do Teradata DBC)	`SELECT * EXCEPT(is_typed) FROM mydataset.INFORMATION_SCHEMA.TABLES;` Para mais informações, consulte Introdução ao BigQuery `INFORMATION_SCHEMA`.
`HELP STATISTICS table_name;`	`APPROX_COUNT_DISTINCT(col)`
`COLLECT STATS USING SAMPLE ON table_name column (...);`	Não usado no BigQuery.
`LOCKING TABLE table_name FOR EXCLUSIVE;`	O BigQuery sempre usa o isolamento de snapshot. Para ver detalhes, consulte Garantias de consistência em outras partes deste documento.
`SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL ...`	O BigQuery sempre usa o isolamento de snapshot. Para ver detalhes, consulte Garantias de consistência em outras partes deste documento.
`BEGIN TRANSACTION; SELECT ... END TRANSACTION;`	O BigQuery sempre usa o isolamento de snapshot. Para ver detalhes, consulte Garantias de consistência em outras partes deste documento.
`EXPLAIN ...`	Não usado no BigQuery. Recursos semelhantes são as explicações do plano de consulta na IU da Web do BigQuery e a alocação visível de slots nas visualizações `INFORMATION_SCHEMA` e no registro de auditoria no Cloud Monitoring.

Instruções SQL com várias instruções e linhas

O Teradata e o BigQuery aceitam transações (sessões) e, portanto, são compatíveis com instruções separadas por ponto e vírgula que são executados consistentemente em conjunto. Para mais informações, consulte Transações de várias instruções.

Mensagens e códigos de erro

Os códigos de erro do Teradata e do BigQuery são diferentes. Ao fornecer uma API REST, o BigQuery depende principalmente de códigos de status HTTP, além de mensagens de erro detalhadas.

Se a lógica do aplicativo estiver detectando os erros a seguir, tente eliminar a origem do erro, já que o BigQuery não retornará os mesmos códigos de erro.

SQLSTATE = '02000' — "Linha não encontrada"
SQLSTATE = '21000' — "Violação de cardinalidade (índice exclusivo)"
SQLSTATE = '22000' — "Violação de dados (tipo de dados)"
SQLSTATE = '23000' — "Violação de restrição"

No BigQuery, seria mais comum usar as visualizações INFORMATION_SCHEMA ou a geração de registros de auditoria para detalhar erros.

Para informações sobre como lidar com erros em scripts, consulte as seções a seguir.

Garantias de consistência e isolamento da transação

O Teradata e o BigQuery são atômicos, ou seja, estão em conformidade com ACID em um nível por mutação em muitas linhas. Por exemplo, uma operação MERGE é completamente atômica, mesmo com vários valores inseridos e atualizados.

Transações

O Teradata fornece nível de isolamento (em inglês) de transações não confirmadas (que permite leituras sujas) ou serializáveis ao executar no modo de sessão, em vez do modo de confirmação automática. Na melhor das hipóteses, o Teradata atinge um isolamento estritamente serializável usando o bloqueio pessimista em um hash de linha em todas as colunas de linhas em todas as partições. Os impasses são possíveis. A DDL sempre força um limite de transação. Os jobs do Teradata Fastload são executados de maneira independente, mas somente em tabelas vazias.

O BigQuery também tem suporte a transações. O BigQuery ajuda a garantir o controle de simultaneidade otimista (primeiro a confirmar) com o isolamento de snapshot, em que uma consulta lê os últimos dados confirmados antes do início da consulta. Essa abordagem garante o mesmo nível de consistência por linha, por mutação e em todas as linhas da mesma instrução DML, evitando impasses. No caso de várias instruções UPDATE na mesma tabela, o BigQuery muda para o controle de simultaneidade pessimista e para várias instruções UPDATE das filas. Elas são repetidas automaticamente em caso de conflitos. A Instrução DML INSERT e os jobs de carregamento podem ser executados de maneira simultânea e independente para anexar às tabelas.

Reverter

O Teradata é compatível com dois modos de reversão de sessão (em inglês), modo de sessão ANSI e modo de sessão Teradata (SET SESSION CHARACTERISTICS e SET SESSION TRANSACTION), dependendo do modo de reversão que você quer. Em casos de falha, a transação pode não ser revertida.

O BigQuery oferece suporte à instrução ROLLBACK TRANSACTION. Não há instrução ABORT no BigQuery.

Limites de bancos de dados

Sempre verifique a documentação pública do BigQuery para ver as cotas e os limites mais recentes. Muitas cotas para usuários de grandes volumes podem ser geradas entrando em contato com a equipe de suporte do Cloud. A tabela a seguir mostra uma comparação dos limites do banco de dados do Teradata e do BigQuery.

Limite	Teradata	BigQuery
Tabelas por banco de dados	Irrestrito	Irrestrito
Colunas por tabela	2.048	10.000
Tamanho máximo da linha	1 MB	100 MB
Tamanho do nome da coluna e da tabela	128 caracteres Unicode	16.384 caracteres Unicode
Linhas por tabela	Ilimitado	Ilimitado
Tamanho máximo da solicitação SQL	1 MB	1 MB (tamanho máximo da consulta GoogleSQL não resolvida) 12 MB (tamanho máximo da consulta legada e do GoogleSQL resolvida) Streaming: 10 MB (limite de tamanho da solicitação HTTP) 10.000 (máximo de linhas por solicitação)
Tamanho máximo da solicitação e da resposta	7 MB (solicitação), 16 MB (resposta)	10 MB (solicitação) e 10 GB (resposta), ou praticamente ilimitado se você usar paginação ou a API Cloud Storage.
Número máximo de sessões simultâneas	120 por mecanismo de análise (PE, na sigla em inglês)	100 consultas simultâneas (podem ser geradas com uma reserva de local), 300 solicitações de API simultâneas por usuário.
Número máximo de carregamentos simultâneos (rápidos)	30 (o padrão é 5)	Nenhum limite de simultaneidade. Jobs estão na fila. 100.000 jobs de carregamento por projeto por dia.

Guia de conversão de SQL do Teradata

Tipos de dados

Formatação de tipo do Teradata

Formatação de carimbo de data/hora e tipo de data

Sintaxe das consultas

Instrução SELECT

Operadores de comparação

JOIN condição

Conversão e transmissão de tipo

Cláusulas QUALIFY e ROWS

Palavra-chave NORMALIZE

Funções

Funções de agregação

Funções de análise e de janela

Funções de data/hora

Funções de string

Funções matemáticas

Sintaxe DML

Instrução INSERT

Instrução UPDATE

Declarações DELETE e TRUNCATE.

Instrução MERGE

Variáveis afetadas por linhas

Sintaxe DDL

Instrução CREATE TABLE

Atributos e opções de coluna

Tabelas temporárias

Instrução CREATE VIEW

Instrução CREATE [UNIQUE] INDEX

Indexação de desempenho

Indexação de consistência (UNIQUE, PRIMARY INDEX)

Indexação para conseguir o bloqueio

Instruções SQL procedurais

Instrução CREATE PROCEDURE

Declaração e atribuição de variáveis

Gerenciadores de condição de erro

Declarações e operações do cursor

Instruções SQL dinâmicas

Instruções de fluxo de controle

Instruções SQL de metadados e transações

Instruções SQL com várias instruções e linhas

Mensagens e códigos de erro

Garantias de consistência e isolamento da transação

Transações

Reverter

Limites de bancos de dados

Instrução `SELECT`

`JOIN` condição

Cláusulas `QUALIFY` e `ROWS`

Palavra-chave `NORMALIZE`

Instrução `INSERT`

Instrução `UPDATE`

Declarações `DELETE` e `TRUNCATE`.

Instrução `MERGE`

Instrução `CREATE TABLE`

Instrução `CREATE VIEW`

Instrução `CREATE [UNIQUE] INDEX`

Instrução `CREATE PROCEDURE`