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 as normas SQL ANSI: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().

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;

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.
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. 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 SQL com padrão ANSI 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:

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:

O Teradata estende as normas 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 SQL com padrão ANSI: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:

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:

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:

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.