Esta página foi traduzida pela API Cloud Translation.

Guia de tradução de SQL do Teradata

Este documento detalha as semelhanças e as diferenças na sintaxe SQL entre o Teradata e o BigQuery para ajudar a planear a sua migração. Use a tradução de SQL em lote para migrar os seus scripts SQL em massa ou a tradução de SQL interativa para traduzir consultas ad hoc.

Tipos de dados

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

Teradata	BigQuery	Notas
`INTEGER`	`INT64`
`SMALLINT`	`INT64`
`BYTEINT`	`INT64`
`BIGINT`	`INT64`
`DECIMAL`	`NUMERIC, DECIMAL` `BIGNUMERIC, BIGDECIMAL`	Use `NUMERIC` do BigQuery (também conhecido como `DECIMAL`) quando a escala (algarismos após o ponto decimal) for <= 9. Use `BIGNUMERIC` do BigQuery (também conhecido como `BIGDECIMAL`) quando a escala for superior a 9. Use os tipos de dados decimais parametrizados do BigQuery se precisar de aplicar limites (restrições) de dígitos ou de escala personalizados. O Teradata permite-lhe inserir valores de maior precisão arredondando o valor armazenado. No entanto, mantém a precisão elevada nos cálculos. Isto pode levar a um comportamento de arredondamento inesperado em comparação com a norma ANSI.
`FLOAT`	`FLOAT64`
`NUMERIC`	`NUMERIC, DECIMAL` `BIGNUMERIC, BIGDECIMAL`	Use `NUMERIC` do BigQuery (também conhecido como `DECIMAL`) quando a escala (algarismos após o ponto decimal) for <= 9. Use `BIGNUMERIC` do BigQuery (também conhecido como `BIGDECIMAL`) quando a escala for superior a 9. Use os tipos de dados decimais parametrizados do BigQuery se precisar de aplicar limites (restrições) de dígitos ou de escala personalizados. O Teradata permite-lhe inserir valores de maior precisão arredondando o valor armazenado. No entanto, mantém a precisão elevada nos cálculos. Isto pode levar a um comportamento de arredondamento inesperado em comparação com a norma ANSI.
`NUMBER`	`NUMERIC, DECIMAL` `BIGNUMERIC, BIGDECIMAL`	Use `NUMERIC` do BigQuery (também conhecido como `DECIMAL`) quando a escala (algarismos após o ponto decimal) for <= 9. Use `BIGNUMERIC` do BigQuery (também conhecido como `BIGDECIMAL`) quando a escala for superior a 9. Use os tipos de dados decimais parametrizados do BigQuery se precisar de aplicar limites (restrições) de dígitos ou de escala personalizados. O Teradata permite-lhe inserir valores de maior precisão arredondando o valor armazenado. No entanto, mantém a precisão elevada nos cálculos. Isto pode levar a um comportamento de arredondamento inesperado em comparação com a norma ANSI.
`REAL`	`FLOAT64`
`CHAR/CHARACTER`	`STRING`	Use o tipo de dados parametrizado do BigQuery se precisar de aplicar um comprimento máximo de carateres.`STRING`
`VARCHAR`	`STRING`	Use o tipo de dados parametrizado do BigQuery se precisar de aplicar um comprimento máximo de carateres.`STRING`
`CLOB`	`STRING`
`JSON`	`JSON`
`BLOB`	`BYTES`
`BYTE`	`BYTES`
`VARBYTE`	`BYTES`
`DATE`	`DATE`	O BigQuery não suporta formatação personalizada semelhante à que o Teradata com o DataForm no SDF suporta.
`TIME`	`TIME`
`TIME WITH TIME ZONE`	`TIME`	O Teradata armazena o tipo de dados `TIME` em UTC e permite-lhe transmitir um desvio do UTC através da sintaxe `WITH TIME ZONE`. O tipo de dados `TIME` no BigQuery representa uma hora independente de qualquer data ou fuso horário.
`TIMESTAMP`	`TIMESTAMP`	Ambos os tipos de dados do Teradata e do BigQuery têm uma precisão de microssegundos (mas o Teradata suporta segundos intercalares, enquanto o BigQuery não).`TIMESTAMP` Os tipos de dados do Teradata e do BigQuery estão normalmente associados a um fuso horário UTC (detalhes).
`TIMESTAMP WITH TIME ZONE`	`TIMESTAMP`	O Teradata `TIMESTAMP` pode ser definido para um fuso horário diferente ao nível do sistema, por utilizador ou por coluna (usando `WITH TIME ZONE`). O tipo `TIMESTAMP` do BigQuery assume UTC se não especificar explicitamente um fuso horário. Certifique-se de que exporta as informações de fuso horário corretamente (não concatene um valor `DATE` e `TIME` sem informações de fuso horário) para que o BigQuery possa convertê-las na importação. Em alternativa, certifique-se de que converte as informações do fuso horário para UTC antes de exportar. O BigQuery tem `DATETIME` para uma abstração entre a hora civil, que não mostra um fuso horário quando é emitida, e `TIMESTAMP`, que é um ponto preciso no tempo que mostra sempre o fuso horário UTC.
`ARRAY`	`ARRAY`
`MULTI-DIMENSIONAL ARRAY`	`ARRAY`	No BigQuery, use uma matriz de structs, com cada struct a conter 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)` deve ser convertido em duas colunas `DATE` que contenham a data de início e a data de fim para que 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 conversão de tipos, consulte a secção seguinte.

Formatação de tipo Teradata

O SQL do Teradata usa um conjunto de formatos predefinidos para apresentar expressões e dados de colunas, bem como para conversões entre tipos de dados. Por exemplo, um tipo de dados PERIOD(DATE) no modo INTEGERDATE é formatado como YY/MM/DD por predefinição. Sugerimos que use o modo ANSIDATE sempre que possível para garantir a conformidade com o SQL ANSI e aproveite esta oportunidade para limpar os formatos antigos.

O Teradata permite a aplicação automática de formatos personalizados através da cláusula FORMAT, sem alterar o armazenamento subjacente, quer como um atributo de tipo de dados quando cria uma tabela através de DDL, quer numa expressão derivada. Por exemplo, uma especificação FORMAT 9.99 arredonda qualquer valor FLOAT para dois dígitos. No BigQuery, esta funcionalidade tem de ser convertida através da função ROUND().

Esta funcionalidade requer o processamento de casos extremos complexos. Por exemplo, quando a cláusula FORMAT é aplicada a uma coluna NUMERIC, tem de ter em conta regras especiais de arredondamento e formatação. Pode usar uma cláusula FORMAT para converter implicitamente um valor de época INTEGER num formato DATE. Em alternativa, uma especificação FORMAT X(6) numa coluna VARCHAR trunca o valor da coluna e, por isso, tem de fazer a conversão para uma função SUBSTR(). Este comportamento não está em conformidade com a norma ANSI SQL. Por isso, sugerimos que não migre os formatos de colunas para o BigQuery.

Se os formatos de colunas forem absolutamente necessários, use vistas ou funções definidas pelo utilizador (FDUs).

Para obter informações sobre os formatos predefinidos que o Teradata SQL usa para cada tipo de dados, consulte a documentação de formatação predefinida do Teradata.

Formatação do tipo de data/hora

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

Formato Teradata	Descrição do Teradata	BigQuery
`CURRENT_TIMESTAMP CURRENT_TIME`	`TIME` e `TIMESTAMP` no Teradata podem ter informações de fuso horário diferentes, que são definidas através de `WITH TIME ZONE`.	Se possível, use `CURRENT_TIMESTAMP()`, que está formatado no formato ISO. No entanto, o formato de saída mostra sempre o fuso horário UTC. (Internamente, o BigQuery não tem um fuso horário.) Tenha em atenção os seguintes detalhes sobre as diferenças no formato ISO. `DATETIME` tem o formato baseado nas convenções do canal de saída. Na ferramenta de linha de comandos do BigQuery e na consola do BigQuery, é formatado com um separador `T` de acordo com a RFC 3339. No entanto, no Python e no Java JDBC, é usado um espaço como separador. Se quiser usar um formato explícito, use `FORMAT_DATETIME()`, que faz uma conversão explícita numa string. Por exemplo, a seguinte expressão devolve sempre um separador de espaço: `CAST(CURRENT_DATETIME() AS STRING)` O Teradata suporta uma palavra-chave `DEFAULT` em colunas `TIME` para definir a hora atual (data/hora); esta não é usada no BigQuery.
`CURRENT_DATE`	As datas são armazenadas no Teradata como valores `INT64` através da 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 devolve sempre uma data no formato ISO 8601. Não é possível usar o `DATE_FROM_UNIX_DATE` porque é baseado em 1970. O Teradata suporta uma palavra-chave `DEFAULT` nas colunas `DATE` para definir a data atual. Esta palavra-chave não é usada no BigQuery.
`CURRENT_DATE-3`	Os valores de data são representados como números inteiros. O Teradata suporta operadores aritméticos para tipos de datas.	Para tipos de data, use `DATE_ADD()` ou `DATE_SUB()`. O BigQuery usa operadores aritméticos para os seguintes tipos de dados: `INT64`, `NUMERIC` e `FLOAT64`.
`SYS_CALENDAR.CALENDAR`	O Teradata fornece uma vista para as operações de calendário irem além das operações de números inteiros.	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 usa sempre o formato ISO 8601. Por isso, certifique-se de que converte as datas e as horas do Teradata.

Sintaxe de consulta

Esta secção aborda as diferenças na sintaxe de consulta entre o Teradata e o BigQuery.

`SELECT` declaração

A maioria das declarações do Teradata SELECT é compatível com o BigQuery. A tabela seguinte contém uma lista de pequenas diferenças.

Teradata		BigQuery
`SEL`		Converter em `SELECT`. O BigQuery não usa a abreviatura `SEL`.
`SELECT (subquery) AS flag, CASE WHEN flag = 1 THEN ...`		No BigQuery, as colunas não podem fazer referência ao resultado de outras colunas definidas na mesma lista de seleção. Preferir 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 lógico `ANY`. A mesma funcionalidade pode ser alcançada através de vários `OR` operadores: `SELECT * FROM table WHERE col LIKE 'string1' OR col LIKE 'string2'` Neste caso, a comparação de strings também é diferente. Consulte os 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 seguinte mostra os operadores de comparação do Teradata que são específicos do Teradata e têm de ser convertidos nos operadores compatíveis com a norma ANSI SQL:2011 usados no BigQuery.

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

Teradata	BigQuery	Notas
`exp EQ exp2` `exp IN (exp2, exp3)`	`exp = exp2` `exp IN (exp2, exp3)` Para manter a semântica não ANSI para `NOT CASESPECIFIC`, pode usar `RTRIM(UPPER(exp)) = RTRIM(UPPER(exp2))`	Quando compara strings quanto à igualdade, o Teradata pode ignorar os espaços em branco finais, enquanto o BigQuery os 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 indica ao Teradata para ignorar a capitalização ao comparar duas strings. O BigQuery é sempre sensível a maiúsculas e minúsculas quando compara 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ções

O BigQuery e o Teradata suportam as mesmas condições JOIN, ON e USING. A tabela seguinte contém uma lista de diferenças menores.

Teradata	BigQuery	Notas
`FROM A JOIN B ON A.date > B.start_date AND A.date < B.end_date`	`FROM A LEFT OUTER JOIN B ON A.date > B.start_date AND A.date < B.end_date`	O BigQuery suporta cláusulas de desigualdade `JOIN` para todas as junções internas ou se for dada, pelo menos, uma condição de igualdade (=). No entanto, não suporta apenas uma condição de desigualdade (= e <) num `OUTER JOIN`. Por vezes, estas construções são usadas para consultar intervalos de datas ou números inteiros. O BigQuery impede que os utilizadores criem inadvertidamente junções cruzadas grandes.
`FROM A, B ON A.id = B.id`	`FROM A JOIN B ON A.id = B.id`	A utilização de uma vírgula entre tabelas no Teradata é igual a um `INNER JOIN`, enquanto no BigQuery é igual a um `CROSS JOIN` (produto cartesiano). Uma vez que a vírgula no SQL antigo do BigQuery é tratada como `UNION`, recomendamos que torne a operação explícita para evitar confusões.
`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 existe 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 utilizadores usem subconsultas, subconsultas correlacionadas ou agregações em predicados de junção. Isto permite que o BigQuery paralelize as consultas.

Conversão de tipos e conversão explícita

O BigQuery tem menos tipos de dados, mas mais abrangentes, do que o Teradata, o que exige que o BigQuery seja mais rigoroso na conversão.

Teradata	BigQuery	Notas
`exp EQ exp2` `exp IN (exp2, exp3)`	`exp = exp2` `exp IN (exp2, exp3)` Para manter a semântica não ANSI para `NOT CASESPECIFIC`, pode usar `RTRIM(UPPER(exp)) = RTRIM(UPPER(exp2))`	Quando compara strings quanto à igualdade, o Teradata pode ignorar os espaços em branco finais, enquanto o BigQuery os 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 indica ao Teradata para ignorar a capitalização ao comparar duas strings. O BigQuery é sempre sensível a maiúsculas e minúsculas quando compara 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 conversão de uma coluna de carateres no Teradata é, por vezes, usada como uma forma não padrão e não ideal de criar uma subcadeia de carateres com preenchimento.
`CAST(92617 AS TIME) 92617 (FORMAT '99:99:99')`	`PARSE_TIME("%k%M%S", CAST(92617 AS STRING))`	O Teradata realiza muito mais conversões de tipos implícitas e arredondamentos do que o BigQuery, que é geralmente mais rigoroso e aplica as normas ANSI. (Este exemplo devolve 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 vírgula flutuante podem exigir regras de arredondamento especiais quando aplicados com formatos como moedas. (Este exemplo devolve 48)

Transmita `FLOAT`/`DECIMAL` para `INT`

Enquanto o Teradata usa algoritmos gaussianos e de banqueiros para arredondar valores numéricos, use a função ROUND_HALF_EVEN RoundingMode no BigQuery:

round(CAST(2.5 as Numeric),0, 'ROUND_HALF_EVEN')

Transmita `STRING` para `NUMERIC` ou `BIGNUMERIC`

Quando converter de STRING para valores numéricos, use o tipo de dados correto, NUMERIC ou BIGNUMERIC, com base no número de casas decimais no valor STRING.

Para mais informações acerca da precisão e da escala numérica suportadas no BigQuery, consulte Tipos decimais.

Consulte também os operadores de comparação e os formatos de colunas. As comparações e a formatação de colunas podem comportar-se como conversões de tipo.

`QUALIFY`, `ROWS` cláusulas

A cláusula QUALIFY no Teradata permite-lhe filtrar resultados para funções de janela. Em alternativa, pode usar a expressão ROWS para a mesma tarefa. Funcionam de forma semelhante a uma condição HAVING para uma cláusula GROUP, limitando a saída do que no BigQuery se chama 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()`, `COUNT()` e com `OVER PARTITION BY`, é expressa no BigQuery como uma cláusula `WHERE` numa subconsulta que contém um valor de análise. Usar `ROW_NUMBER()`: `SELECT col1, col2 FROM ( SELECT col1, col2, ROW_NUMBER() OVER (PARTITION BY col1 ORDER BY col2) RN FROM table ) WHERE RN = 1;` Usar `ARRAY_AGG`, que suporta 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, pode usar `RANGE` e `ROWS` na cláusula de intervalo. No entanto, as cláusulas de janela só podem ser usadas com funções de janela, como `AVG()`, e não com funções de numeração, como `ROW_NUMBER()`.
`SELECT col1, col2 FROM table QUALIFY ROW_NUMBER() OVER (PARTITION BY col1 ORDER BY col2) = 1;`	`SELECT col1, col2 FROM Dataset-name.table QUALIFY row_number() OVER (PARTITION BY upper(a.col1) ORDER BY upper(a.col2)) = 1`

`NORMALIZE` palavra-chave

O Teradata fornece a palavra-chave NORMALIZE para cláusulas SELECT para unir períodos ou intervalos sobrepostos num único período ou intervalo que abranja todos os valores de períodos individuais.

O BigQuery não suporta o tipo PERIOD, pelo que qualquer coluna do tipo PERIOD no Teradata tem de ser inserida 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 secções seguintes listam os mapeamentos entre as funções do Teradata e os equivalentes do BigQuery.

Funções de agregação

A tabela seguinte mapeia as funções de agregação comuns do Teradata, de agregação estatística e de agregação aproximada para os respetivos equivalentes do BigQuery. O BigQuery oferece as seguintes funções de agregação adicionais:

Teradata	BigQuery
`AVG`	`AVG` Nota: o BigQuery fornece resultados aproximados quando calcula a média de valores `INT`.
`BITAND`	`BIT_AND`
`BITNOT`	Operador NOT bit a 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`	Função definida pelo utilizador personalizada.
`STDDEV_POP`	`STDDEV_POP`
`STDDEV_SAMP`	`STDDEV_SAMP, STDDEV`
`SUM`	`SUM`
`VAR_POP`	`VAR_POP`
`VAR_SAMP`	`VAR_SAMP, VARIANCE`

Funções analíticas e funções de janela

A tabela seguinte mapeia as funções analíticas e analíticas agregadas comuns do Teradata para os respetivos equivalentes de funções 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`	Operador NOT bit a 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`
`QUANTILE`	`NTILE`
`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 seguinte mapeia as funções de data/hora comuns do Teradata para as respetivas equivalentes do BigQuery. O BigQuery oferece as seguintes funções de data/hora adicionais:

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` Nota: esta função suporta 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 seguinte mapeia as funções de strings do Teradata com os respetivos equivalentes do BigQuery. O BigQuery oferece as seguintes funções de strings adicionais:

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 definida pelo utilizador personalizada.
`CSVLD`	Função definida pelo utilizador personalizada.
`FORMAT`	`FORMAT`
`INDEX`	`STRPOS(string, substring)`
`INITCAP`	`INITCAP`
`INSTR`	Função definida pelo utilizador personalizada.
`LEFT`	`SUBSTR(source_string, 1, length)`
`LENGTH`	`LENGTH`
`LOWER`	`LOWER`
`LPAD`	`LPAD`
`LTRIM`	`LTRIM`
`NGRAM`	Função definida pelo utilizador personalizada.
`NVP`	Função definida pelo utilizador personalizada.
`OREPLACE`	`REPLACE`
`OTRANSLATE`	Função definida pelo utilizador personalizada.
`POSITION`	`STRPOS(string, substring)`
`REGEXP_INSTR`	`STRPOS(source_string, REGEXP_EXTRACT(source_string, regexp_string))` Nota: devolve 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 definida pelo utilizador personalizada.
`REVERSE`	`REVERSE`
`RIGHT`	`SUBSTR(source_string, -1, length)`
`RPAD`	`RPAD`
`RTRIM`	`RTRIM`
`STRTOK` Nota: cada caráter no argumento da string de delimitador é considerado um caráter delimitador separado. O delimitador predefinido é um caráter de espaço.	`SPLIT(instring, delimiter)[ORDINAL(tokennum)]` Nota: o argumento de string delimitador completo é usado como um único delimitador. O delimitador predefinido é uma vírgula.
`STRTOK_SPLIT_TO_TABLE`	Função definida pelo utilizador personalizada
`SUBSTRING`, `SUBSTR`	`SUBSTR`
`TRIM`	`TRIM`
`UPPER`	`UPPER`

Funções matemáticas

A tabela seguinte mapeia as funções matemáticas do Teradata para os respetivos equivalentes do BigQuery. O BigQuery oferece as seguintes funções matemáticas adicionais:

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

Funções de arredondamento

Enquanto o Teradata usa algoritmos gaussianos e de banqueiros para arredondar valores numéricos, use a função ROUND_HALF_EVEN RoundingMode no BigQuery:


-- Teradata syntax
round(3.45,1)

-- BigQuery syntax
round(CAST(3.45 as Numeric),1, 'ROUND_HALF_EVEN')

Sintaxe DML

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

`INSERT` declaração

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

Os scripts DML no BigQuery têm uma semântica de consistência ligeiramente diferente das declarações equivalentes no Teradata. Para uma vista geral do isolamento de instantâneos e do processamento de sessões e transações, consulte a secção CREATE INDEX noutro local 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.

Nota: no BigQuery, a omissão dos nomes das colunas na declaração INSERT só funciona se os valores de todas as colunas na tabela de destino estiverem incluídos por ordem ascendente com base nas respetivas 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. Nota: no BigQuery, a omissão dos nomes das colunas na declaração `INSERT` só funciona se os valores de todas as colunas na tabela de destino estiverem incluídos por ordem ascendente com base nas respetivas 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 pedido de várias declarações (MSR), que envia várias `INSERT`declarações de uma vez. No BigQuery, isto não é recomendado devido ao limite de transação implícito entre declarações. Em alternativa, use vários valores `INSERT`. O BigQuery permite declarações `INSERT` simultâneas, mas pode colocá-las em fila`UPDATE`. Para melhorar o desempenho, considere as seguintes abordagens: Combine várias linhas numa única declaração `INSERT`, em vez de uma linha por operação `INSERT`. Combine várias declarações DML (incluindo `INSERT`) com uma declaração `MERGE`. Use `CREATE TABLE ... AS SELECT` para criar e preencher novas tabelas em vez de `UPDATE` ou `DELETE`, em particular quando 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 pedido de várias declarações (MSR), que envia várias INSERTdeclarações de uma vez. No BigQuery, isto não é recomendado devido ao limite de transação implícito entre declarações. Em alternativa, use vários valores INSERT.

O BigQuery permite declarações INSERT simultâneas, mas pode colocá-las em filaUPDATE. Para melhorar o desempenho, considere as seguintes abordagens:

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

`UPDATE` declaração

A maioria das declarações do Teradata são compatíveis com o BigQuery, exceto os seguintes itens:UPDATE

Quando usa uma cláusula FROM, a ordem das cláusulas FROM e SET é invertida no Teradata e no BigQuery.
No GoogleSQL, cada declaração UPDATE tem de incluir a palavra-chave WHERE, seguida de uma condição. Para atualizar todas as linhas na tabela, use WHERE true.

Como prática recomendada, deve agrupar várias mutações de DML em vez de declarações únicas UPDATE e INSERT. Os scripts DML no BigQuery têm uma semântica de consistência ligeiramente diferente das declarações equivalentes no Teradata. Para uma vista geral do isolamento de instantâneos e do processamento de sessões e transações, consulte a secção CREATE INDEX noutro local deste documento.

A tabela seguinte mostra declarações do Teradata e declarações do BigQuery que realizam as mesmas tarefas.UPDATE

Para mais informações sobre o UPDATE no BigQuery, consulte os exemplos do UPDATE do BigQuery na documentação da 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;`

`DELETE` e `TRUNCATE` extratos

As declarações DELETE e TRUNCATE são formas suportadas de remover linhas de uma tabela sem afetar o esquema ou os índices da tabela. TRUNCATE elimina todos os dados, enquanto DELETE remove as linhas selecionadas da tabela.

No BigQuery, a declaração DELETE tem de ter uma cláusula WHERE. Para eliminar todas as linhas na tabela (truncar), use WHERE true. Para acelerar as operações de truncagem em tabelas muito grandes, recomendamos que use a declaração CREATE OR REPLACE TABLE ... AS SELECT, usando um LIMIT 0 na mesma tabela para se substituir. No entanto, certifique-se de que adiciona manualmente informações de particionamento e agrupamento quando o usar.

O Teradata elimina as linhas eliminadas mais tarde. Isto significa que as operações DELETE são inicialmente mais rápidas do que no BigQuery, mas requerem recursos posteriormente, 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, por exemplo, copiando as linhas que não devem ser eliminadas para uma nova tabela. Em alternativa, pode remover partições inteiras. Ambas as opções foram concebidas para serem operações mais rápidas do que as mutações de DML atómicas.

Para mais informações sobre DELETE no BigQuery, consulte os DELETE exemplos na documentação da 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;`	A substituição do conteúdo de uma tabela pela saída de uma consulta é equivalente a uma transação. Pode fazê-lo com uma operação de consulta ou uma operação de cópia. Usar uma operação de consulta: `bq query --replace --destination_table table_A 'SELECT * FROM table_B';` Usar uma operação de cópia: `bq cp -f table_A table_B`
`DELETE database.table ALL;`	`DELETE FROM table WHERE TRUE;` Em alternativa, para tabelas muito grandes, pode usar um método mais rápido: `CREATE OR REPLACE table AS SELECT * FROM table LIMIT 0;`

`MERGE` declaração

A declaração MERGE pode combinar operações INSERT, UPDATE e DELETE numa única declaração "upsert" e executar as operações de forma atómica. A operação MERGE tem de 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 da Teradata está MERGElimitada à correspondência de chaves primárias num processador de módulo de acesso (AMP). Por outro lado, o BigQuery não tem limitações de tamanho nem de colunas para as operações MERGE. Por isso, usar MERGE é uma otimização útil. No entanto, se a MERGE for principalmente uma eliminação grande, consulte as otimizações para DELETE noutras partes deste 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 duplicados durante uma operação MERGE. Para uma vista geral sobre o processamento de tabelas MULTISET e SET, o isolamento de instantâneos e o processamento de sessões e transações, consulte a secção CREATE INDEX noutro local deste documento.

Variáveis de linhas afetadas

No Teradata, a variável ACTIVITY_COUNT é uma extensão SQL ANSI do Teradata preenchida com o número de linhas afetadas por uma declaração DML.

A @@row_count variável de sistema na funcionalidade de scripting tem uma funcionalidade semelhante. No BigQuery, é mais comum verificar o valor de retorno numDmlAffectedRows nos registos de auditoria ou nas vistas INFORMATION_SCHEMA.

Sintaxe DDL

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

`CREATE TABLE` declaração

A maioria das declarações do Teradata CREATE TABLE é compatível com o BigQuery, exceto os seguintes elementos de sintaxe, que não são usados no BigQuery:

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

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

Opções e atributos de colunas

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

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

O Teradata expande a norma ANSI com uma opção de coluna TITLE. Esta funcionalidade pode ser implementada de forma semelhante no BigQuery usando a descrição da coluna, conforme mostrado na tabela seguinte. Tenha em atenção que esta 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 suporta tabelas voláteis, que são frequentemente usadas para armazenar resultados intermédios em scripts. Existem várias formas de conseguir algo semelhante às tabelas voláteis no BigQuery:

CREATE TEMPORARY TABLE pode ser usado em Scripts, e é válido durante a duração do script. Se a tabela tiver de existir para além de um script, pode usar as outras opções nesta lista.
Tempo de vida (TTL) do conjunto de dados: crie um conjunto de dados com um tempo de vida curto (por exemplo, 1 hora) para que todas as tabelas criadas no conjunto de dados sejam efetivamente temporárias, uma vez que não persistem mais tempo do que o tempo de vida do conjunto de dados. Pode adicionar o prefixo temp a todos os nomes das tabelas neste conjunto de dados para indicar claramente que as tabelas são temporárias.
TTL da tabela: crie uma tabela com um tempo de vida curto específico da tabela através de declaraçõ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 precisar de uma tabela temporária apenas no mesmo bloco, use um resultado temporário com uma declaração WITH ou uma subconsulta. Esta é a opção mais eficiente.

Um padrão usado frequentemente em scripts do Teradata (BTEQ) é criar uma tabela permanente, inserir um valor na mesma, usá-la como uma tabela temporária em declarações em curso e, em seguida, eliminar ou truncar a tabela. Na prática, isto usa a tabela como uma variável constante (um semáforo). Esta abordagem não é eficiente no BigQuery e recomendamos que use variáveis reais em vez disso, ou use CREATE OR REPLACE com a sintaxe de consulta AS SELECT para criar uma tabela que já tenha valores.

`CREATE VIEW` declaração

A tabela seguinte mostra os equivalentes entre o Teradata e o BigQuery para a declaração CREATE VIEW. As cláusulas para o bloqueio de tabelas, como LOCKING ROW FOR ACCESS, não são necessárias no BigQuery.

Teradata	BigQuery	Notas
`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 suportado	`CREATE VIEW IF NOT EXISTS OPTIONS(view_option_list) AS SELECT ...`	Cria uma nova vista apenas se a vista não existir atualmente no conjunto de dados especificado.

`CREATE [UNIQUE] INDEX` declaração

O Teradata requer índices para todas as tabelas e soluções alternativas especiais, como tabelas MULTISET e NoPI Tables, para funcionar com dados não únicos ou não indexados.

O BigQuery não requer índices. Esta secção descreve abordagens no BigQuery para criar uma funcionalidade semelhante à forma como os índices são usados no Teradata, onde existe uma necessidade real de lógica empresarial.

Indexação para desempenho

Uma vez que é uma base de dados orientada para colunas com otimização de consultas e armazenamento, o BigQuery não precisa de índices explícitos. O BigQuery oferece funcionalidades como a divisão e o agrupamento, bem como campos aninhados, que podem aumentar a eficiência e o desempenho das consultas ao otimizar a forma como os dados são armazenados.

O Teradata não suporta visualizações de propriedades materializadas. No entanto, oferece índices de junção através da declaração CREATE JOIN INDEX, que materializa essencialmente os dados necessários para uma junção. O BigQuery não precisa de índices materializados para acelerar o desempenho, tal como não precisa de espaço de spool dedicado para junções.

Para outros casos de otimização, podem ser usadas vistas materializadas.

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

No Teradata, pode usar um índice único para impedir linhas com chaves não únicas numa tabela. Se um processo tentar inserir ou atualizar dados que tenham um valor já presente no índice, a operação falha com uma violação do índice (tabelas MULTISET) ou ignora-o silenciosamente (tabelas SET).

Uma vez que o BigQuery não fornece índices explícitos, pode usar uma declaração MERGE para inserir apenas registos únicos numa tabela de destino a partir de uma tabela de preparação, ao mesmo tempo que rejeita registos duplicados. No entanto, não existe forma de impedir que um utilizador com autorizações de edição insira um registo duplicado, porque o BigQuery nunca é bloqueado durante as operações INSERT. Para gerar um erro para registos duplicados no BigQuery, pode usar uma declaração MERGE de uma tabela de preparação, conforme mostrado no exemplo seguinte.

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

Mais frequentemente, os utilizadores preferem remover duplicados de forma independente para encontrar erros nos sistemas a jusante.
O BigQuery não suporta colunas DEFAULT e IDENTITY (sequências).

Indexação para alcançar o bloqueio

O Teradata fornece recursos no processador do módulo de acesso (AMP); as consultas podem consumir recursos de todos os AMPs, de um único AMP ou de um grupo de AMPs. As declarações DDL são totalmente AMP e, por isso, semelhantes a um bloqueio DDL global. O BigQuery não tem um mecanismo de bloqueio como este e pode executar consultas e declarações INSERT concorrentes até à sua quota; apenas as declarações DML UPDATE concorrentes têm determinadas implicações de concorrência: as operações UPDATE contra a mesma partição são colocadas em fila para garantir o isolamento de instantâneos, pelo que não tem de bloquear para evitar leituras fantasma ou atualizações perdidas.

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

ON COMMIT DELETE ROWS;
ON COMMIT PRESERVE ROWS;

Declarações SQL processuais

Esta secção descreve como converter declarações SQL processuais usadas em procedimentos armazenados, funções e acionadores do Teradata para scripts, procedimentos ou funções definidas pelo utilizador (FDUs) do BigQuery. Todas estas opções estão disponíveis para os administradores do sistema verificarem através das visualizações INFORMATION_SCHEMA.

`CREATE PROCEDURE` declaração

Os procedimentos armazenados são suportados como parte do Scripting do BigQuery.

No BigQuery, os scripts referem-se a qualquer utilização de declarações de controlo, enquanto os procedimentos são scripts com nome (com argumentos, se necessário) que podem ser chamados a partir de outros scripts e armazenados permanentemente, se necessário. Uma função definida pelo utilizador (FDU) também pode ser escrita em JavaScript.

Teradata	BigQuery
`CREATE PROCEDURE`	`CREATE PROCEDURE` se for necessário um nome, caso contrário, use inline com `BEGIN` ou numa única linha com `CREATE TEMP FUNCTION`.
`REPLACE PROCEDURE`	`CREATE OR REPLACE PROCEDURE`
`CALL`	`CALL`

As secções seguintes descrevem formas de converter declarações processuais do Teradata existentes em declarações de scripts do BigQuery com uma funcionalidade semelhante.

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

As variáveis do BigQuery são válidas durante a vida útil do script.

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

Controladores de condições de erro

O Teradata usa processadores em códigos de estado em procedimentos para controlo de erros. No BigQuery, o processamento de erros é uma funcionalidade essencial do fluxo de controlo principal, semelhante ao que outras linguagens oferecem 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 controladores de exceções que são acionados para determinadas condições de erro não são usados pelo BigQuery. Recomendamos a utilização de declarações `ASSERT` quando as condições de saída são usadas para verificações prévias ou depuração, porque estão em conformidade com a norma ANSI SQL:2011.

A variável SQLSTATE no Teradata é semelhante à variável de sistema @@error no BigQuery. No BigQuery, é mais comum investigar erros através do registo de auditoria ou das vistas INFORMATION_SCHEMA.

Declarações e operações do cursor

Uma vez que o BigQuery não suporta cursores nem sessões, as seguintes declaraçõ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;

Declarações SQL dinâmicas

A funcionalidade de scripts no BigQuery suporta declarações SQL dinâmicas, como as apresentadas na tabela seguinte.

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

As seguintes declarações de SQL dinâmico não são usadas no BigQuery:

PREPARE stmt_id FROM sql_str;

Declarações de fluxo de controlo

A funcionalidade de scripts no BigQuery suporta declarações de fluxo de controlo, como as apresentadas na tabela seguinte.

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;`	As construções de blocos ao estilo GOTO não são usadas no BigQuery. Recomendamos que as reescreva como funções definidas pelo utilizador (FDUs) ou use declarações `ASSERT` onde são usadas para processamento de erros.
`REPEAT stmts UNTIL condition END REPEAT;`	`WHILE condition DO stmts END WHILE`
`LEAVE outer_proc_label;`	`LEAVE` não é usado para blocos de estilo GOTO; é usado como sinónimo de `BREAK` para sair de um ciclo `WHILE`.
`LEAVE label;`	`LEAVE` não é usado para blocos de estilo GOTO; é usado como sinónimo de `BREAK` para sair de um ciclo `WHILE`.
`WITH RECURSIVE temp_table AS ( ... );`	As consultas recursivas (também conhecidas como expressões de tabelas comuns recursivas [CTE]) não são usadas no BigQuery. Podem ser reescritas através de matrizes de `UNION ALL`.

As seguintes declarações de fluxo de controlo não são usadas no BigQuery porque o BigQuery não usa cursores nem sessões:

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

Metadados e declarações SQL de 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 obter informações de colunas para visualizações. Para mais informações, consulte a vista de coluna no BigQuery `INFORMATION_SCHEMA`.
`SELECT * FROM dbc.tables WHERE tablekind = 'T';` (Vista DBC do Teradata)	`SELECT * EXCEPT(is_typed) FROM mydataset.INFORMATION_SCHEMA.TABLES;` Para mais informações, consulte a 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 usa sempre o isolamento de instantâneos. Para ver detalhes, consulte Garantias de consistência noutra parte deste documento.
`SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL ...`	O BigQuery usa sempre o isolamento de instantâneos. Para ver detalhes, consulte a secção Garantias de consistência neste documento.
`BEGIN TRANSACTION; SELECT ... END TRANSACTION;`	O BigQuery usa sempre o isolamento de instantâneos. Para ver detalhes, consulte a secção Garantias de consistência neste documento.
`EXPLAIN ...`	Não usado no BigQuery. As funcionalidades semelhantes são a explicação do plano de consulta na IU da Web do BigQuery e a atribuição de slots visível nas `INFORMATION_SCHEMA` vistas e no registo de auditoria no Cloud Monitoring.
`BEGIN TRANSACTION; SELECT ... END TRANSACTION;`	`BEGIN BEGIN TRANSACTION; COMMIT TRANSACTION; EXCEPTION WHEN ERROR THEN -- Roll back the transaction inside the exception handler. SELECT @@error.message; ROLLBACK TRANSACTION; END;`

Declarações SQL multilinhas e com várias declarações

O Teradata e o BigQuery suportam transações (sessões) e, por isso, suportam declarações separadas por pontos e vírgulas que são executadas em conjunto de forma consistente. Para mais informações, consulte o artigo Transações com vários extratos.

Códigos e mensagens de erro

Os códigos de erro do Teradata e os códigos de erro do BigQuery são diferentes. Ao fornecer uma API REST, o BigQuery baseia-se principalmente em códigos de estado HTTP e em mensagens de erro detalhadas.

Se a lógica da sua aplicação estiver a detetar os seguintes erros, experimente eliminar a origem do erro, porque o BigQuery não devolve os mesmos códigos de erro.

SQLSTATE = '02000'—"Linha não encontrada"
SQLSTATE = '21000'—"Cardinality violation (Unique Index)"
SQLSTATE = '22000'—"Violação de dados (tipo de dados)"
SQLSTATE = '23000'—"Constraint Violation"

No BigQuery, é mais comum usar as visualizações INFORMATION_SCHEMA ou o registo de auditoria para analisar detalhadamente os erros.

Para informações sobre como processar erros nos scripts, consulte as secções que se seguem.

Garantias de consistência e isolamento de transações

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

Transações

O Teradata fornece o nível de isolamento de transações de leitura não comprometida (que permite leituras sujas) ou serializável quando é executado no modo de sessão (em vez do modo de confirmação automática). No melhor dos casos, o Teradata alcança o isolamento estritamente serializável através do bloqueio pessimista em relação a um hash de linhas em todas as colunas de linhas em todas as partições. Podem ocorrer impasses. O DDL força sempre um limite de transação. As tarefas do Teradata Fastload são executadas de forma independente, mas apenas em tabelas vazias.

O BigQuery também suporta transações. O BigQuery ajuda a garantir o controlo de concorrência otimista (o primeiro a confirmar ganha) com o isolamento de instantâneos, em que uma consulta lê os últimos dados confirmados antes de começar. Esta abordagem garante o mesmo nível de consistência por linha, por mutação e entre linhas na mesma declaração DML, mas evita bloqueios. No caso de várias declarações UPDATE na mesma tabela, o BigQuery muda para o controlo de concorrência pessimista e coloca em fila várias declarações UPDATE, repetindo automaticamente em caso de conflitos. INSERT As declarações DML e os trabalhos de carregamento podem ser executados em simultâneo e de forma independente para anexar a tabelas.

Reversão

O Teradata suporta dois modos de reversão de sessão, o modo de sessão ANSI e o modo de sessão Teradata (SET SESSION CHARACTERISTICS e SET SESSION TRANSACTION), consoante o modo de reversão que pretender. Nos casos de falha, a transação pode não ser revertida.

O BigQuery suporta a declaração ROLLBACK TRANSACTION. Não existe nenhuma declaração ABORT no BigQuery.

Limites da base de dados

Verifique sempre a documentação pública do BigQuery para conhecer as quotas e os limites mais recentes. Muitas quotas para utilizadores de grande volume podem ser aumentadas contactando a equipa de apoio técnico do Google Cloud. A tabela seguinte mostra uma comparação dos limites da base de dados do Teradata e do BigQuery.

Limite	Teradata	BigQuery
Tabelas por base de dados	Sem restrições	Sem restrições
Colunas por tabela	2048	10 000
Tamanho máximo da linha	1 MB	100 MB
Comprimento do nome da coluna	128 carateres Unicode	300 carateres Unicode
Comprimento da descrição da tabela	128 carateres Unicode	16 384 carateres Unicode
Linhas por tabela	Ilimitado	Ilimitado
Comprimento máximo do pedido SQL	1 MB	1 MB (comprimento máximo da consulta GoogleSQL não resolvida) 12 MB (comprimento máximo da consulta GoogleSQL e antiga resolvida) Streaming: 10 MB (limite de tamanho do pedido HTTP) 10 000 (máximo de linhas por pedido)
Tamanho máximo do pedido e da resposta	7 MB (pedido), 16 MB (resposta)	10 MB (pedido) e 10 GB (resposta) ou praticamente ilimitado se usar a paginação ou a API Cloud Storage.
Número máximo de sessões simultâneas	120 por motor de análise (PE)	1000 consultas com várias declarações em simultâneo (podem ser aumentadas com uma reserva de espaço), 300 pedidos de API em simultâneo por utilizador.
Número máximo de carregamentos (rápidos) simultâneos	30 (predefinição: 5)	Sem limite de simultaneidade; as tarefas são colocadas em fila de espera. 100 000 tarefas de carregamento por projeto por dia.