Guía de traducción de SQL de Teradata

En este documento, se detallan las similitudes y diferencias que existen en la sintaxis de SQL de Teradata y BigQuery para ayudarte a planificar tu migración. Usa la traducción de SQL por lotes para migrar tus secuencias de comandos de SQL de forma masiva o la traducción de SQL interactiva a fin de traducir consultas ad hoc.

Tipos de datos

En esta sección, se muestran los equivalentes entre los tipos de datos en Teradata y en BigQuery.

Teradata	BigQuery	Notas
`INTEGER`	`INT64`
`SMALLINT`	`INT64`
`BYTEINT`	`INT64`
`BIGINT`	`INT64`
`DECIMAL`	`NUMERIC, DECIMAL` `BIGNUMERIC, BIGDECIMAL`	Usa `NUMERIC` de BigQuery (alias `DECIMAL`) cuando la escala (dígitos después del punto decimal) <= 9. Usa `BIGNUMERIC` de BigQuery (alias `BIGDECIMAL`) cuando la escala sea mayor que 9. Usa los tipos de datos decimales parametrizados de BigQuery si necesitas aplicar dígitos personalizados o límites de escala (restricciones). Teradata te permite insertar valores de mayor precisión mediante el redondeo del valor almacenado. Sin embargo, mantiene la alta precisión en los cálculos. Esto puede generar un comportamiento de redondeo inesperado en comparación con el estándar ANSI.
`FLOAT`	`FLOAT64`
`NUMERIC`	`NUMERIC, DECIMAL` `BIGNUMERIC, BIGDECIMAL`	Usa `NUMERIC` de BigQuery (alias `DECIMAL`) cuando la escala (dígitos después del punto decimal) <= 9. Usa `BIGNUMERIC` de BigQuery (alias `BIGDECIMAL`) cuando la escala sea mayor que 9. Usa los tipos de datos decimales parametrizados de BigQuery si necesitas aplicar dígitos personalizados o límites de escala (restricciones). Teradata te permite insertar valores de mayor precisión mediante el redondeo del valor almacenado. Sin embargo, mantiene la alta precisión en los cálculos. Esto puede generar un comportamiento de redondeo inesperado en comparación con el estándar ANSI.
`NUMBER`	`NUMERIC, DECIMAL` `BIGNUMERIC, BIGDECIMAL`	Usa `NUMERIC` de BigQuery (alias `DECIMAL`) cuando la escala (dígitos después del punto decimal) <= 9. Usa `BIGNUMERIC` de BigQuery (alias `BIGDECIMAL`) cuando la escala sea mayor que 9. Usa los tipos de datos decimales parametrizados de BigQuery si necesitas aplicar dígitos personalizados o límites de escala (restricciones). Teradata te permite insertar valores de mayor precisión mediante el redondeo del valor almacenado. Sin embargo, mantiene la alta precisión en los cálculos. Esto puede generar un comportamiento de redondeo inesperado en comparación con el estándar ANSI.
`REAL`	`FLOAT64`
`CHAR/CHARACTER`	`STRING`	Usa el tipo de datos `STRING` parametrizado de BigQuery si necesitas aplicar una longitud máxima de caracteres.
`VARCHAR`	`STRING`	Usa el tipo de datos `STRING` parametrizado de BigQuery si necesitas aplicar una longitud máxima de caracteres.
`CLOB`	`STRING`
`JSON`	`JSON`
`BLOB`	`BYTES`
`BYTE`	`BYTES`
`VARBYTE`	`BYTES`
`DATE`	`DATE`	BigQuery no admite formatos personalizados similares a los que admite Teradata con DataForm en SDF.
`TIME`	`TIME`
`TIME WITH TIME ZONE`	`TIME`	Teradata almacena el tipo de datos `TIME` en UTC y te permite pasar un desplazamiento de UTC mediante la sintaxis `WITH TIME ZONE` . El tipo de datos `TIME` en BigQuery representa una hora que es independiente de cualquier fecha o zona horaria.
`TIMESTAMP`	`TIMESTAMP`	Los tipos de datos `TIMESTAMP` de Teradata y BigQuery tienen precisión de microsegundos (pero Teradata admite segundos bisiestos, al contrario de BigQuery). Los tipos de datos de Teradata y BigQuery suelen estar asociados con una zona horaria UTC (detalles).
`TIMESTAMP WITH TIME ZONE`	`TIMESTAMP`	La `TIMESTAMP` de Teradata se puede establecer en una zona horaria diferente en todo el sistema, por usuario o por columna (mediante `WITH TIME ZONE`). El tipo `TIMESTAMP` de BigQuery usa UTC si no especificas una zona horaria de forma explícita. Asegúrate de exportar de forma correcta la información de la zona horaria (no debes concatenar un valor `DATE` y un valor `TIME` sin información de la zona horaria) para que BigQuery pueda convertirla en la importación. Como alternativa, asegúrate de convertir la información de la zona horaria en UTC antes de exportarla. BigQuery tiene `DATETIME` para una abstracción entre la hora civil, que no muestra una zona horaria cuando se genera, y `TIMESTAMP`, que es un punto preciso en el tiempo que siempre muestra la zona horaria UTC.
`ARRAY`	`ARRAY`
`MULTI-DIMENSIONAL ARRAY`	`ARRAY`	En BigQuery, usa un arreglo de structs, en el que cada struct contenga un campo del tipo `ARRAY` (para obtener más detalles, consulta la documentación de 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)` debe convertirse en dos columnas `DATE` que contengan la fecha de inicio y de finalización para que puedan usarse con funciones analíticas.
`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 obtener más información sobre la conversión de tipos, consulta la siguiente sección.

Formatos de tipos de Teradata

SQL de Teradata usa un conjunto de formatos predeterminados a fin de mostrar expresiones y datos de columnas y para conversiones entre tipos de datos. Por ejemplo, un tipo de datos PERIOD(DATE) en modo INTEGERDATE tiene el formato YY/MM/DD de forma predeterminada. Te sugerimos usar el modo ANSIDATE siempre que sea posible a fin de garantizar el cumplimiento del estándar ANSI SQL y aprovechar esta oportunidad para descartar los formatos heredados.

Teradata permite la aplicación automática de formatos personalizados mediante la cláusula FORMAT, sin cambiar el almacenamiento subyacente, ya sea como un atributo de tipo de datos cuando creas una tabla mediante DDL o en una expresión derivada. Por ejemplo, una especificación de FORMAT 9.99 redondea cualquier valor FLOAT a dos dígitos. En BigQuery, esta función debe convertirse mediante la función ROUND().

Esta función necesita controlar casos extremos complejos. Por ejemplo, cuando se aplica la cláusula FORMAT a una columna NUMERIC, debes tener en cuenta las reglas de formateo y redondeo especiales. Se puede usar una cláusula FORMAT para convertir de manera implícita un valor INTEGER de ciclo de entrenamiento en un formato DATE. También puede ocurrir que una especificación de FORMAT X(6) en una columna VARCHAR trunque el valor de la columna y, por lo tanto, se deba convertir en una función SUBSTR(). Este comportamiento no cumple con el estándar ANSI SQL. Por lo tanto, sugerimos no migrar los formatos de columna a BigQuery.

Si los formatos de columna son obligatorios, usa vistas o funciones definidas por el usuario (UDF).

A fin de obtener información sobre los formatos predeterminados que SQL de Teradata usa para cada tipo de datos, consulta la documentación sobre formatos predeterminados de Teradata.

Tipos de formato de marca de tiempo y fecha

En la siguiente tabla, se resumen las diferencias en los elementos de formato de fecha y marca de tiempo entre el SQL de Teradata y GoogleSQL.

Formato de Teradata	Descripción de Teradata	BigQuery
`CURRENT_TIMESTAMP CURRENT_TIME`	La información de `TIME` y `TIMESTAMP` en Teradata puede tener datos de zonas horarias diferentes, que se definen mediante `WITH TIME ZONE`.	Si es posible, usa `CURRENT_TIMESTAMP()`, que tiene formato ISO. Sin embargo, el formato de salida siempre muestra la zona horaria UTC. (A nivel interno, BigQuery no tiene una zona horaria). Ten en cuenta los siguientes detalles sobre las diferencias en el formato ISO. El formato de `DATETIME` se basa en las convenciones del canal de salida. En la herramienta de línea de comandos y la consola de BigQuery, se le da formato mediante un separador `T` según el estándar RFC 3339. Sin embargo, en JDBC de Python y Java, se usa un espacio como separador. Si quieres usar un formato explícito, usa `FORMAT_DATETIME()`, que hace que una conversión explícita sea una string. Por ejemplo, la siguiente expresión siempre muestra un separador de espacios: `CAST(CURRENT_DATETIME() AS STRING)` Teradata admite una palabra clave `DEFAULT` en las columnas `TIME` para establecer la hora actual (marca de tiempo). En cambio, eso no sucede en BigQuery.
`CURRENT_DATE`	Las fechas se almacenan en Teradata como valores `INT64` mediante la siguiente fórmula: `(YEAR - 1900) * 10000 + (MONTH * 100) + DAY` Las fechas pueden tener el formato de números enteros.	BigQuery tiene un formato `DATE` independiente que siempre muestra una fecha en formato ISO 8601. No se puede usar `DATE_FROM_UNIX_DATE` porque se basa en 1970. Teradata admite una palabra clave `DEFAULT` en columnas `DATE` para establecer la fecha actual. En cambio, eso no sucede en BigQuery.
`CURRENT_DATE-3`	Los valores de fecha se representan como números enteros. Teradata admite operadores aritméticos para tipos de fecha.	Para los tipos de fecha, usa `DATE_ADD()` o `DATE_SUB()`. BigQuery usa operadores aritméticos para tipos de datos: `INT64`, `NUMERIC` y `FLOAT64`.
`SYS_CALENDAR.CALENDAR`	Teradata proporciona una vista para que las operaciones de calendario vayan más allá de las operaciones de números enteros.	No se usa en BigQuery.
`SET SESSION DATEFORM=ANSIDATE`	Establece el formato de fecha de la sesión o del sistema en ANSI (ISO 8601).	BigQuery siempre usa ISO 8601, así que asegúrate de convertir las fechas y horas de Teradata.

Sintaxis de las consultas

En esta sección, se abordan las diferencias que existen en la sintaxis de consultas en Teradata y en BigQuery.

Declaración `SELECT`

La mayoría de las declaraciones SELECT de Teradata son compatibles con BigQuery. En la siguiente tabla, se incluye una lista de diferencias menores.

Teradata		BigQuery
`SEL`		Se convierte en `SELECT`. BigQuery no usa la abreviatura `SEL`.
`SELECT (subquery) AS flag, CASE WHEN flag = 1 THEN ...`		En BigQuery, las columnas no pueden hacer referencia al resultado de otras columnas definidas dentro de la misma lista de selección. Es preferible mover una subconsulta a una cláusula `WITH`. `WITH flags AS ( subquery ), SELECT CASE WHEN flags.flag = 1 THEN ...`
`SELECT * FROM table WHERE A LIKE ANY ('string1', 'string2')`		BigQuery no usa el predicado lógico `ANY`. La misma funcionalidad se puede lograr mediante varios operadores `OR`: `SELECT * FROM table WHERE col LIKE 'string1' OR col LIKE 'string2'` En este caso, la comparación de strings también difiere. Consulta Operadores de comparación.
`SELECT TOP 10 * FROM table`		BigQuery usa `LIMIT` al final de una consulta en lugar de `TOP n` después de la palabra clave `SELECT`.

Operadores de comparación

En la siguiente tabla, se muestran los operadores de comparación de Teradata que son específicos de Teradata y deben convertirse en los operadores compatibles con ANSI SQL:2011 que se usan en BigQuery.

Para obtener información sobre los operadores en BigQuery, consulta la sección Operadores de la documentación de BigQuery.

Teradata	BigQuery	Notas
`exp EQ exp2` `exp IN (exp2, exp3)`	`exp = exp2` `exp IN (exp2, exp3)` A fin de mantener una semántica que no cumpla con ANSI para `NOT CASESPECIFIC`, puedes usar `RTRIM(UPPER(exp)) = RTRIM(UPPER(exp2))`	Durante las comparaciones de igualdad de strings, es posible que Teradata ignore los espacios en blanco iniciales y finales, mientras que BigQuery los considera parte de la string. Por ejemplo, `'xyz'=' xyz'` es `TRUE` en Teradata, pero `FALSE` en BigQuery. Teradata también proporciona un atributo de columna `NOT CASESPECIFIC` que le indica a Teradata que ignore las mayúsculas y minúsculas cuando se comparan dos strings. BigQuery siempre distingue entre mayúsculas y minúsculas cuando se comparan strings. Por ejemplo, `'xYz' = 'xyz'` es `TRUE` en Teradata, pero `FALSE` en 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` condiciones

BigQuery y Teradata admiten las mismas condiciones JOIN, ON y USING. En la siguiente tabla, se incluye una lista de diferencias menores.

Teradata	BigQuery	Notas
`FROM A LEFT OUTER JOIN B ON A.date > B.start_date AND A.date < B.end_date`	`FROM A LEFT OUTER JOIN (SELECT d FROM B JOIN UNNEST(GENERATE_DATE_ARRAY(B.start_date, B.end_date)) d) B ON A.date = B.date`	BigQuery admite cláusulas `JOIN` de desigualdad para todas las uniones internas o si se da al menos una condición de igualdad (=), pero no admite una sola condición de desigualdad (= y <) en una `OUTER JOIN`. Estas construcciones a veces se usan para consultar rangos de fechas o de números enteros. BigQuery evita que los usuarios creen grandes uniones cruzadas por accidente.
`FROM A, B ON A.id = B.id`	`FROM A JOIN B ON A.id = B.id`	Usar una coma entre tablas en Teradata equivale a una `INNER JOIN`, mientras que en BigQuery equivale a una `CROSS JOIN` (producto cartesiano). Debido a que la coma en SQL heredado de BigQuery se trata como `UNION`, recomendamos que la operación sea explícita para evitar confusiones.
`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))`	No hay diferencias entre las funciones 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`	BigQuery evita que los usuarios usen subconsultas, subconsultas correlacionadas o agregaciones en los predicados de la unión. Esto permite que BigQuery realice consultas paralelas.

Transmisión y conversión de tipos

BigQuery tiene menos tipos de datos, pero estos son más amplios que Teradata, lo que requiere que BigQuery sea más estricto en la transmisión.

Teradata	BigQuery	Notas
`exp EQ exp2` `exp IN (exp2, exp3)`	`exp = exp2` `exp IN (exp2, exp3)` A fin de mantener una semántica que no cumpla con ANSI para `NOT CASESPECIFIC`, puedes usar `RTRIM(UPPER(exp)) = RTRIM(UPPER(exp2))`	Durante las comparaciones de igualdad de strings, es posible que Teradata ignore los espacios en blanco iniciales y finales, mientras que BigQuery los considera parte de la string. Por ejemplo, `'xyz'=' xyz'` es `TRUE` en Teradata, pero `FALSE` en BigQuery. Teradata también proporciona un atributo de columna `NOT CASESPECIFIC` que le indica a Teradata que ignore las mayúsculas y minúsculas cuando se comparan dos strings. BigQuery siempre distingue entre mayúsculas y minúsculas cuando se comparan strings. Por ejemplo, `'xYz' = 'xyz'` es `TRUE` en Teradata, pero `FALSE` en BigQuery.
`CAST(long_varchar_column AS CHAR(6))`	`LPAD(long_varchar_column, 6)`	La transmisión de una columna de caracteres en Teradata a veces se usa como una forma no estándar y no óptima de crear una substring con relleno.
`CAST(92617 AS TIME) 92617 (FORMAT '99:99:99')`	`PARSE_TIME("%k%M%S", CAST(92617 AS STRING))`	Teradata realiza muchas más conversiones implícitas y operaciones de redondeo que BigQuery, que en general es más estricto y aplica los estándares ANSI. (En este ejemplo, se muestra 9:26:17)
`CAST(48.5 (FORMAT 'zz') AS FLOAT)`	`CAST(SUBSTR(CAST(48.5 AS STRING), 0, 2) AS FLOAT64)`	Los tipos de datos de punto flotante y numéricos pueden requerir reglas de redondeo especiales cuando se aplican con formatos como monedas. (En este ejemplo, se muestra 48)

Consulta también las secciones sobre operadores de comparación y formatos de columna. Tanto las comparaciones como el formateo de columnas pueden comportarse como conversiones de tipo.

Cláusulas `QUALIFY`, `ROWS`

La cláusula QUALIFY en Teradata te permite filtrar resultados para funciones analíticas. Como alternativa, se puede usar una frase ROWS para la misma tarea. Estas frases funcionan de manera similar a una condición HAVING para una cláusula GROUP, lo que limita el resultado de lo que en BigQuery se llaman funciones analíticas.

Teradata BigQuery

SELECT col1, col2 FROM table QUALIFY ROW_NUMBER() OVER (PARTITION BY col1 ORDER BY col2) = 1; La cláusula QUALIFY de Teradata con una función analítica como ROW_NUMBER(), SUM() o COUNT() y con OVER PARTITION BY se expresa en BigQuery como una cláusula WHERE en la subconsulta que contiene el valor analítico.

Mediante ROW_NUMBER():

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

Mediante ARRAY_AGG, que admite particiones más grandes:

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

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

En BigQuery, se pueden usar RANGE y ROWS en la cláusula de marco de ventana. Sin embargo, las cláusulas analíticas solo se pueden usar con funciones analíticas como AVG(), no con funciones de numeración como ROW_NUMBER().

Teradata	BigQuery
`SELECT col1, col2 FROM table QUALIFY ROW_NUMBER() OVER (PARTITION BY col1 ORDER BY col2) = 1;`	La cláusula `QUALIFY` de Teradata con una función analítica como `ROW_NUMBER()`, `SUM()` o `COUNT()` y con `OVER PARTITION BY` se expresa en BigQuery como una cláusula `WHERE` en la subconsulta que contiene el valor analítico. Mediante `ROW_NUMBER()`: `SELECT col1, col2 FROM ( SELECT col1, col2, ROW_NUMBER() OVER (PARTITION BY col1 ORDER BY col2) RN FROM table ) WHERE RN = 1;` Mediante `ARRAY_AGG`, que admite particiones más grandes: `SELECT result.* FROM ( SELECT ARRAY_AGG(table ORDER BY table.col2 DESC LIMIT 1)[OFFSET(0)] FROM table GROUP BY col1 ) AS result;`
`SELECT col1, col2 FROM table AVG(col1) OVER (PARTITION BY col1 ORDER BY col2 ROWS BETWEEN 2 PRECEDING AND CURRENT ROW);`	`SELECT col1, col2 FROM table AVG(col1) OVER (PARTITION BY col1 ORDER BY col2 RANGE BETWEEN 2 PRECEDING AND CURRENT ROW);` En BigQuery, se pueden usar `RANGE` y `ROWS` en la cláusula de marco de ventana. Sin embargo, las cláusulas analíticas solo se pueden usar con funciones analíticas como `AVG()`, no con funciones de numeración como `ROW_NUMBER()`.

Palabra clave `NORMALIZE`

Teradata proporciona la palabra clave NORMALIZE para las cláusulas SELECT para fusionar períodos o intervalos superpuestos en un solo período o intervalo que abarque todos los valores de períodos individuales.

BigQuery no admite el tipo PERIOD, por lo que cualquier columna de tipo PERIOD en Teradata debe insertarse en BigQuery como dos campos DATE o DATETIME independientes que correspondan al inicio y al final del 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;

Funciones

En las siguientes secciones, se muestra una lista de las funciones de Teradata junto con las funciones equivalentes de BigQuery.

Funciones de agregación

En la siguiente tabla, se muestran las funciones comunes de agregación, agregación estadística y agregación aproximada de Teradata junto con las funciones equivalentes de BigQuery. BigQuery ofrece las siguientes funciones de agregación adicionales:

Teradata	BigQuery
`AVG`	`AVG`
`BITAND`	`BIT_AND`
`BITNOT`	Operador NOT a nivel de bits (`~`)
`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`	Función personalizada definida por el usuario.
`STDDEV_POP`	`STDDEV_POP`
`STDDEV_SAMP`	`STDDEV_SAMP, STDDEV`
`SUM`	`SUM`
`VAR_POP`	`VAR_POP`
`VAR_SAMP`	`VAR_SAMP, VARIANCE`

Funciones analíticas de Teradata y BigQuery

En la siguiente tabla, se muestra la relación entre las funciones analíticas y de agregación comunes de Teradata y las funciones analíticas equivalentes de BigQuery. BigQuery ofrece las siguientes funciones adicionales:

Teradata	BigQuery
`ARRAY_AGG`	`ARRAY_AGG`
`ARRAY_CONCAT, (\|\| operator)`	`ARRAY_CONCAT_AGG, (\|\| operator)`
`BITAND`	`BIT_AND`
`BITNOT`	Operador NOT a nivel de bits (`~`)
`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`

Funciones de fecha y hora

En la siguiente tabla, se muestran las funciones de fecha y hora comunes de Teradata junto con sus equivalentes de BigQuery. BigQuery ofrece las siguientes funciones adicionales de fecha y 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` Nota: Esta función admite expresiones de entrada `DATE` y `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`

Funciones de string

En la siguiente tabla, se muestran las funciones de string de Teradata junto con las funciones equivalentes de BigQuery. BigQuery ofrece las siguientes funciones de string adicionales:

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`	Función personalizada definida por el usuario.
`CSVLD`	Función personalizada definida por el usuario.
`FORMAT`	`FORMAT`
`INDEX`	`STRPOS(string, substring)`
`INITCAP`	`INITCAP`
`INSTR`	Función personalizada definida por el usuario.
`LEFT`	`SUBSTR(source_string, 1, length)`
`LENGTH`	`LENGTH`
`LOWER`	`LOWER`
`LPAD`	`LPAD`
`LTRIM`	`LTRIM`
`NGRAM`	Función personalizada definida por el usuario.
`NVP`	Función personalizada definida por el usuario.
`OREPLACE`	`REPLACE`
`OTRANSLATE`	Función personalizada definida por el usuario.
`POSITION`	`STRPOS(string, substring)`
`REGEXP_INSTR`	`STRPOS(source_string, REGEXP_EXTRACT(source_string, regexp_string))` Nota: Muestra el primer caso.
`REGEXP_REPLACE`	`REGEXP_REPLACE`
`REGEXP_SIMILAR`	`IF(REGEXP_CONTAINS,1,0)`
`REGEXP_SUBSTR`	`REGEXP_EXTRACT, REGEXP_EXTRACT_ALL`
`REGEXP_SPLIT_TO_TABLE`	Función personalizada definida por el usuario.
`REVERSE`	`REVERSE`
`RIGHT`	`SUBSTR(source_string, -1, length)`
`RPAD`	`RPAD`
`RTRIM`	`RTRIM`
`STRTOK` Nota: Cada carácter en el argumento de string delimitador se considera un carácter delimitador independiente. El delimitador predeterminado es un carácter de espacio.	`SPLIT(instring, delimiter)[ORDINAL(tokennum)]` Nota: El argumento de string delimitador completo se usa como único delimitador. El delimitador predeterminado es una coma.
`STRTOK_SPLIT_TO_TABLE`	Función personalizada definida por el usuario
`SUBSTRING`, `SUBSTR`	`SUBSTR`
`TRIM`	`TRIM`
`UPPER`	`UPPER`

Funciones matemáticas

En la siguiente tabla, se muestran las funciones matemáticas de Teradata junto con las funciones equivalentes de BigQuery. BigQuery ofrece las siguientes funciones matemáticas adicionales:

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

Sintaxis del DML

En esta sección, se abordan las diferencias que existen entre la sintaxis del lenguaje de administración de datos de Teradata y de BigQuery.

Declaración `INSERT`

La mayoría de las declaraciones INSERT de Teradata son compatibles con BigQuery. En la siguiente tabla, se muestran las excepciones.

Las secuencias de comandos del DML en BigQuery tienen una semántica de coherencia apenas diferente de la que tienen las declaraciones equivalentes de Teradata. Para obtener una descripción general del aislamiento de instantáneas y el control de sesiones y transacciones, consulta la sección CREATE INDEX en este documento.

Teradata BigQuery

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

Teradata ofrece una palabra clave DEFAULT para las columnas que no admiten valores nulos.

Nota: En BigQuery, omitir los nombres de las columnas en la declaración INSERT solo funciona si los valores de todas las columnas de la tabla de destino se incluyen en orden ascendente según sus posiciones ordinales.

Teradata	BigQuery
`INSERT INTO table VALUES (...);`	`INSERT INTO table (...) VALUES (...);` Teradata ofrece una palabra clave `DEFAULT` para las columnas que no admiten valores nulos. Nota: En BigQuery, omitir los nombres de las columnas en la declaración `INSERT` solo funciona si los valores de todas las columnas de la tabla de destino se incluyen en orden ascendente según sus posiciones ordinales.
`INSERT INTO table VALUES (1,2,3); INSERT INTO table VALUES (4,5,6); INSERT INTO table VALUES (7,8,9);`	`INSERT INTO table VALUES (1,2,3), (4,5,6), (7,8,9);` Teradata tiene un modelo de solicitud de varias declaraciones (MSR), que envía varias declaraciones `INSERT` a la vez. En BigQuery, esto no se recomienda debido al límite de transacciones implícito entre las declaraciones. En su lugar, usa el valor múltiple `INSERT`. BigQuery permite declaraciones `INSERT` simultáneas, pero podría poner en cola a la declaración `UPDATE`. Para mejorar el rendimiento, considera los siguientes enfoques: Combina varias filas en una sola declaración `INSERT`, en lugar de una fila por operación `INSERT`. Combina varias declaraciones DML (incluida `INSERT`) mediante una declaración `MERGE`. Usa `CREATE TABLE ... AS SELECT` para crear y propagar tablas nuevas en lugar de `UPDATE` o `DELETE`, en particular cuando consultes campos particionados o reversiones o restablecimientos.


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

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

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


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

                         (4,5,6),

                         (7,8,9);

Teradata tiene un modelo de solicitud de varias declaraciones (MSR), que envía varias declaraciones INSERT a la vez. En BigQuery, esto no se recomienda debido al límite de transacciones implícito entre las declaraciones. En su lugar, usa el valor múltiple INSERT.

BigQuery permite declaraciones INSERT simultáneas, pero podría poner en cola a la declaración UPDATE. Para mejorar el rendimiento, considera los siguientes enfoques:

Combina varias filas en una sola declaración INSERT, en lugar de una fila por operación INSERT.
Combina varias declaraciones DML (incluida INSERT) mediante una declaración MERGE.
Usa CREATE TABLE ... AS SELECT para crear y propagar tablas nuevas en lugar de UPDATE o DELETE, en particular cuando consultes campos particionados o reversiones o restablecimientos.

Declaración `UPDATE`

La mayoría de las declaraciones UPDATE de Teradata son compatibles con BigQuery, excepto los siguientes elementos:

Cuando usas una cláusula FROM, el orden de las cláusulas FROM y SET se invierte en Teradata y BigQuery.
En GoogleSQL, cada instrucción UPDATE debe incluir la palabra clave WHERE, seguida de una condición. Para actualizar todas las filas de la tabla, usa WHERE true.

Como práctica recomendada, debes agrupar varias transformaciones DML en lugar de declaraciones UPDATE y INSERT individuales. Las secuencias de comandos del DML en BigQuery tienen una semántica de coherencia apenas diferente de la que tienen las declaraciones equivalentes de Teradata. Para obtener una descripción general del aislamiento de instantáneas y el control de sesiones y transacciones, consulta la sección CREATE INDEX en cualquier otra parte de este documento.

En la siguiente tabla, se muestran las declaraciones UPDATE de Teradata y las declaraciones de BigQuery que realizan las mismas tareas.

Para obtener más información sobre UPDATE en BigQuery, consulta los ejemplos de UPDATE de BigQuery en la documentación del 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;`

Declaraciones `DELETE` y `TRUNCATE`

Las declaraciones DELETE y TRUNCATE son alternativas para quitar filas de una tabla sin afectar el esquema ni los índices de esta. TRUNCATE no se usa en Teradata ni en BigQuery. Sin embargo, puedes usar declaraciones DELETE para obtener el mismo resultado.

En BigQuery, la declaración DELETE debe tener una cláusula WHERE. Para borrar todas las filas de la tabla (truncar), usa WHERE true. Para acelerar las operaciones de truncamiento en tablas muy grandes, te recomendamos usar la declaración CREATE OR REPLACE TABLE ... AS SELECT, mediante un LIMIT 0 en la misma tabla para que se reemplace. Sin embargo, asegúrate de agregar de forma manual la información de la partición y el agrupamiento en clústeres cuando la uses.

Teradata se deshace de las filas borradas más tarde. Esto significa que, al principio, las operaciones DELETE son más rápidas que en BigQuery, pero requieren recursos más adelante, en especial las operaciones DELETE a gran escala que afectan la mayor parte de una tabla. Para usar un enfoque similar en BigQuery, sugerimos reducir la cantidad de operaciones DELETE, por ejemplo, mediante el copiado de las filas que no se borrarán en una tabla nueva. Como alternativa, puedes quitar particiones completas. Ambas opciones están diseñadas para ser operaciones más rápidas que las transformaciones atómicas del DML.

Para obtener más información sobre DELETE en BigQuery, consulta los ejemplos de DELETE en la documentación del 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;`	El equivalente a una transacción es reemplazar el contenido de una tabla por el resultado de la consulta. Puedes hacerlo con una operación de consulta o una operación de copiado. Usa una operación de consulta: `bq query --replace --destination_table table_A 'SELECT * FROM table_B';` Usa una operación de copiado: `bq cp -f table_A table_B`
`DELETE database.table ALL;`	`DELETE FROM table WHERE TRUE;` Para tablas muy grandes, esta es una opción más rápida: `CREATE OR REPLACE table AS SELECT * FROM table LIMIT 0;`

Declaración `MERGE`

La declaración MERGE puede combinar declaraciones INSERT, UPDATE y DELETE en una sola declaración “upsert” y realizar las operaciones de forma atómica. La operación MERGE debe vincular como máximo una fila de origen con cada fila de destino. BigQuery y Teradata siguen la sintaxis ANSI.

La operación MERGE de Teradata se limita vincular las claves primarias en un procesador de módulo de acceso (AMP). Por el contrario, BigQuery no tiene un límite de tamaño ni de columna para las operaciones MERGE, por lo que usar MERGE es una optimización útil. Sin embargo, si MERGE implica una eliminación grande, consulta las optimizaciones para DELETE en otra parte de este documento.

Las secuencias de comandos del DML en BigQuery tienen una semántica de coherencia apenas diferente de la que tienen las declaraciones equivalentes de Teradata. Por ejemplo, las tablas SET de Teradata en modo de sesión pueden ignorar duplicados durante una operación MERGE. Para obtener una descripción general del manejo de tablas MULTISET y SET, el aislamiento de instantáneas y el control de transacciones y sesiones, consulta la sección CREATE INDEX de este documento.

Variables afectadas por filas

En Teradata, la variable ACTIVITY_COUNT es una extensión de ANSI SQL de Teradata propagada con la cantidad de filas que afecta una declaración DML.

La variable de sistema @@row_count en el scripting tiene funciona de manera similar. En BigQuery, sería más común verificar el valor de retorno numDmlAffectedRows en los registros de auditoría o en las vistas INFORMATION_SCHEMA.

Sintaxis del DDL

En esta sección, se abordan las diferencias que existen entre la sintaxis del lenguaje de definición de datos en Teradata y en BigQuery.

Declaración `CREATE TABLE`

La mayoría de las declaraciones CREATE TABLE de Teradata son compatibles con BigQuery, excepto los siguientes elementos de la sintaxis, que no se usan en BigQuery:

MULTISET. Consulta la sección CREATE INDEX
VOLATILE. Consulta la sección Tablas temporales
[NO] FALLBACK Consulta la sección Reversión
[NO] BEFORE JOURNAL, [NO] AFTER JOURNAL
CHECKSUM = DEFAULT | val
DEFAULT MERGEBLOCKRATIO
PRIMARY INDEX (col, ...). Consulta la sección CREATE INDEX
UNIQUE PRIMARY INDEX. Consulta la sección CREATE INDEX
CONSTRAINT
DEFAULT
IDENTITY

Para obtener más información sobre CREATE TABLE en BigQuery, consulta los ejemplos de CREATE de BigQuery en la documentación del DML.

Atributos y opciones de columnas

Las siguientes especificaciones de columna para la declaración CREATE TABLE no se usan en BigQuery:

FORMAT 'format' Consulta la sección Formato de tipos de Teradata
CHARACTER SET name. BigQuery siempre usa la codificación UTF-8
[NOT] CASESPECIFIC
COMPRESS val | (val, ...)

Teradata extiende el estándar ANSI con una opción de columna TITLE. Esta función se puede implementar de manera similar en BigQuery mediante la descripción de la columna, como se muestra en la siguiente tabla. Ten en cuenta que esta opción no está disponible para las vistas.

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

Tablas temporales

Teradata admite tablas variables, que a menudo se usan para almacenar resultados intermedios en secuencias de comandos. Existen varias formas de lograr algo similar a las tablas variables en BigQuery:

CREATE TEMPORARY TABLE se puede usar en el scripting y es válido durante la vida útil de la secuencia de comandos. Si la tabla debe seguir existiendo una vez terminada la vida útil de una secuencia de comandos, puedes usar las otras opciones de esta lista.
TTL del conjunto de datos: Crea un conjunto de datos con un tiempo de actividad corto (por ejemplo, 1 hora) para que las tablas creadas en el conjunto de datos sean temporales, ya que no durarán más que el tiempo de actividad del conjunto de datos. Puedes poner prefijos en todos los nombres de las tablas de este conjunto de datos mediante temp para indicar con claridad que las tablas son temporales.
TTL de la tabla: Crea una tabla que tenga un tiempo de actividad específico para la tabla mediante declaraciones del DDL similares a las siguientes:
```
CREATE TABLE temp.name (col1, col2, ...)
OPTIONS(expiration_timestamp=TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL 1 HOUR));
```
Cláusula WITH: Si se necesita una tabla temporal solo dentro del mismo bloque, usa un resultado temporal mediante una declaración o subconsulta WITH. Esta es la opción más eficiente.

Un patrón que se usa con frecuencia en las secuencias de comandos de Teradata (BTEQ) consiste en crear una tabla permanente, insertar un valor en ella, usarla como una tabla temporal en las declaraciones en curso y, luego, borrarla o truncarla. En efecto, esto usa la tabla como una variable constante (un semáforo). Este enfoque no es eficiente en BigQuery y recomendamos usar variables reales en el scripting o usar CREATE OR REPLACE con la sintaxis de consulta AS SELECT para crear una tabla que ya tenga valores.

Declaración `CREATE VIEW`

En la siguiente tabla, se muestran equivalencias de la declaración CREATE VIEW entre Teradata y BigQuery. Las cláusulas para el bloqueo de tablas, como LOCKING ROW FOR ACCESS, no son necesarias dentro de 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 ...`
No compatible	`CREATE VIEW IF NOT EXISTS OPTIONS(view_option_list) AS SELECT ...`	Crea una vista nueva solo si la vista no existe en el conjunto de datos especificado.

Declaración `CREATE [UNIQUE] INDEX`

Teradata requiere índices para todas las tablas y soluciones especiales, como tablas MULTISET y NoPI Tables, para trabajar con datos que no sean únicos o no estén indexados.

BigQuery no requiere índices. En esta sección, se describen los enfoques en BigQuery para crear una funcionalidad similar al uso de los índices en Teradata, en la que existe una necesidad lógica empresarial real.

Indexa en favor del rendimiento

BigQuery no necesita índices explícitos, ya que es una base de datos orientada a columnas con optimización de consultas y almacenamiento. BigQuery proporciona funciones como la partición y el agrupamiento en clústeres, además de los campos anidados, que pueden aumentar la eficiencia y el rendimiento de las consultas mediante la optimización de la forma en que se almacenan los datos.

Teradata no admite vistas materializadas. Sin embargo, ofrece índices de unión mediante la declaración CREATE JOIN INDEX, que materializa los datos necesarios para una unión. BigQuery no necesita índices materializados a fin de acelerar el rendimiento, del mismo modo que no necesita un espacio en cola dedicado para las uniones.

Para otros casos de optimización, se pueden usar vistas materializadas.

Indexa en favor de la coherencia (UNIQUE, PRIMARY INDEX)

En Teradata, se puede usar un índice único para evitar filas con claves que no sean únicas en una tabla. Si un proceso intenta insertar o actualizar datos que tienen un valor que ya está en el índice, la operación falla y muestra un incumplimiento del índice (tablas MULTISET) o ignora el proceso sin mostrar ningún aviso (tablas SET).

Debido a que BigQuery no proporciona índices explícitos, se puede usar una declaración MERGE en su lugar para insertar solo registros únicos en una tabla de destino desde una tabla de etapa de pruebas y descartar los registros duplicados. Sin embargo, no hay forma de evitar que un usuario con permisos de edición inserte un registro duplicado, ya que BigQuery nunca se bloquea durante las operaciones INSERT. A fin de generar un error para los registros duplicados en BigQuery, puedes usar una declaración MERGE desde una tabla de etapa de pruebas, como se muestra en el siguiente ejemplo.

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

Por lo general, los usuarios prefieren quitar los duplicados de forma independiente para encontrar errores en los sistemas posteriores.
BigQuery no admite las columnas DEFAULT ni IDENTITY (secuencias).

Indexa en favor del bloqueo

Teradata proporciona recursos en el procesador del módulo de acceso (AMP); las consultas pueden consumir recursos de todos los AMP, de un solo AMP o de un grupo de AMP. Las declaraciones DDL son de todo el AMP y, por lo tanto, son similares a un bloqueo del DDL global. BigQuery no tiene un mecanismo de bloqueo como este y puede ejecutar consultas simultáneas y declaraciones INSERT según tu cuota. Solo las declaraciones DML UPDATE simultáneas tienen ciertas implicaciones de simultaneidad: las operaciones UPDATE en la misma partición se ponen en cola a fin de garantizar el aislamiento de instantáneas, por lo que no tienes que bloquearlas para evitar lecturas fantasma o actualizaciones perdidas.

Debido a estas diferencias, los siguientes elementos de Teradata no se usan en BigQuery:

ON COMMIT DELETE ROWS;
ON COMMIT PRESERVE ROWS;

Instrucciones de SQL de procedimiento

En esta sección, se describe cómo convertir las instrucciones de SQL de procedimiento que se usan en funciones, activadores y procedimientos almacenados de Teradata en scripting, procedimientos o funciones definidas por el usuario (UDF) de BigQuery. Todo esto está disponible para que los administradores de sistemas lo verifiquen mediante las vistas INFORMATION_SCHEMA.

Declaración `CREATE PROCEDURE`

Los procedimientos almacenados son compatibles con el scripting de BigQuery.

En BigQuery, el término scripting se refiere a cualquier uso de declaraciones de control, mientras que los procedimientos se denominan secuencias de comandos (con argumentos si es necesario) y se pueden llamar desde otras secuencias de comandos y almacenar de forma permanente, si se necesita. Una función definida por el usuario (UDF) también se puede escribir en JavaScript.

Teradata	BigQuery
`CREATE PROCEDURE`	Usa `CREATE PROCEDURE` si se requiere un nombre; de lo contrario, úsalo intercalado con `BEGIN` o en una sola línea con `CREATE TEMP FUNCTION`.
`REPLACE PROCEDURE`	`CREATE OR REPLACE PROCEDURE`
`CALL`	`CALL`

En las siguientes secciones, se describen las maneras de convertir las declaraciones de procedimiento de Teradata existentes en declaraciones de scripting de BigQuery que funcionan de manera similar.

Declaración y asignación de variables

Las variables de BigQuery son válidas durante la vida útil de la secuencia de comandos.

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

Controladores de condiciones de error

Teradata usa controladores en los códigos de estado de los procedimientos para el control de errores. En BigQuery, el control de errores es una función principal del flujo de control principal, similar a lo que proporcionan otros lenguajes con bloques 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;`	BigQuery no usa controladores de excepciones que se activan para ciertas condiciones de error. Recomendamos usar instrucciones `ASSERT` en las que las condiciones de salida se usan para las verificaciones previas o la depuración, ya que esto cumple con el ANSI SQL:2011.

La variable SQLSTATE en Teradata es similar a la variable del sistema @@error en BigQuery. En BigQuery, es más común investigar errores mediante el registro de auditoría o las vistas INFORMATION_SCHEMA.

Declaraciones y operaciones del cursor

Debido a que BigQuery no admite cursores ni sesiones, las siguientes declaraciones no se usan en 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;

Instrucciones de SQL dinámicas

La función de secuencia de comandos en BigQuery admite instrucciones de SQL dinámicas como las que se muestran en la siguiente tabla.

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

Las siguientes instrucciones de SQL dinámicas no se usan en BigQuery:

PREPARE stmt_id FROM sql_str;

Instrucciones de flujo de control

La función de scripting en BigQuery admite instrucciones de flujo de control como las que se muestran en la siguiente tabla.

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;`	Las construcciones de bloque de estilo GOTO no se usan en BigQuery. Recomendamos que se vuelvan a escribir como funciones definidas por el usuario (UDF) o se usen instrucciones `ASSERT` en las que se usan para manejar errores.
`REPEAT stmts UNTIL condition END REPEAT;`	`WHILE condition DO stmts END WHILE`
`LEAVE outer_proc_label;`	`LEAVE` no se usa para bloques de estilo GOTO; se usa como sinónimo de `BREAK` con el fin de dejar un bucle `WHILE`.
`LEAVE label;`	`LEAVE` no se usa para bloques de estilo GOTO; se usa como sinónimo de `BREAK` con el fin de dejar un bucle `WHILE`.
`WITH RECURSIVE temp_table AS ( ... );`	No se usan consultas recurrentes (también conocidas como expresiones de tabla comunes [CTE] recurrentes) en BigQuery. Se pueden volver a escribir con arreglos de `UNION ALL`.

No se usan las siguientes instrucciones de flujo de control en BigQuery porque BigQuery no usa cursores ni sesiones:

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

Instrucciones de SQL de transacciones y metadatos

Teradata	BigQuery
`HELP TABLE table_name;` `HELP VIEW view_name;`	`SELECT * EXCEPT(is_generated, generation_expression, is_stored, is_updatable) FROM mydataset.INFORMATION_SCHEMA.COLUMNS; WHERE table_name=table_name` La misma consulta es válida con el fin de obtener información de columnas para las vistas. Para obtener más información, consulta la vista de columnas en `INFORMATION_SCHEMA` de BigQuery.
`SELECT * FROM dbc.tables WHERE tablekind = 'T';` (Vista DBC de Teradata)	`SELECT * EXCEPT(is_typed) FROM mydataset.INFORMATION_SCHEMA.TABLES;` Para obtener más información, consulta Introducción a BigQuery `INFORMATION_SCHEMA`.
`HELP STATISTICS table_name;`	`APPROX_COUNT_DISTINCT(col)`
`COLLECT STATS USING SAMPLE ON table_name column (...);`	No se usa en BigQuery.
`LOCKING TABLE table_name FOR EXCLUSIVE;`	BigQuery siempre usa el aislamiento de instantáneas. Para obtener más información, consulta Garantías de coherencia en este documento.
`SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL ...`	BigQuery siempre usa el aislamiento de instantáneas. Para obtener más información, consulta Garantías de coherencia en este documento.
`BEGIN TRANSACTION; SELECT ... END TRANSACTION;`	BigQuery siempre usa el aislamiento de instantáneas. Para obtener más información, consulta Garantías de coherencia en este documento.
`EXPLAIN ...`	No se usa en BigQuery. Las funciones similares son la explicación del plan de consultas en la IU web de BigQuery y la asignación de ranuras visible en las vistas `INFORMATION_SCHEMA` y en el registro de auditoría en Cloud Monitoring.

Instrucciones de SQL de varias instrucciones y varias líneas

Teradata y BigQuery admiten transacciones (sesiones) y, por lo tanto, admiten declaraciones separadas por punto y coma que se ejecutan juntas de manera coherente. Para obtener más información, consulta Transacciones de varias declaraciones.

Mensajes y códigos de error

Los códigos de error de Teradata y los de BigQuery son diferentes. BigQuery se basa en gran medida en códigos de estado HTTP y proporciona una API de REST, además de mensajes de error detallados.

Si la lógica de tu aplicación detecta los siguientes errores, intenta quitar la fuente del error, ya que BigQuery no mostrará los mismos códigos de error.

SQLSTATE = '02000': “Fila no encontrada”
SQLSTATE = '21000': “Incumplimiento de la cardinalidad (Índice único)”
SQLSTATE = '22000': “Incumplimiento de datos (Tipo de datos)”
SQLSTATE = '23000': “Incumplimiento de restricción”

En BigQuery, sería más común usar las vistas INFORMATION_SCHEMA o el registro de auditoría para desglosar los errores.

Para obtener información sobre cómo controlar los errores en el scripting, consulta las siguientes secciones.

Garantías de coherencia y aislamiento de transacción

Tanto Teradata como BigQuery son atómicos, es decir, cumplen con el estándar ACID en un nivel por transformación en muchas filas. Por ejemplo, una operación MERGE es atómica por completo, incluso con varios valores insertados y actualizados.

Transacciones

Teradata proporciona nivel de aislamiento de lecturas no confirmadas (que permite lecturas no sincronizadas) o de transacciones serializables cuando se ejecuta en modo de sesión (en lugar de en modo de confirmación automática). En el mejor de los casos, Teradata logra un aislamiento estrictamente serializable mediante el bloqueo pesimista en el hash de una fila en todas las columnas de filas en todas las particiones. Los interbloqueos son posibles. DDL siempre aplica un límite de transacciones. Los trabajos FastLoad de Teradata se ejecutan de forma independiente, pero solo en tablas vacías.

BigQuery también admite transacciones. BigQuery ayuda a garantizar el control de simultaneidad optimista (gana el primero en confirmarse) con el aislamiento de instantáneas, de modo que una consulta lea los últimos datos que se confirmaron antes de comenzar la consulta. Este enfoque garantiza el mismo nivel de coherencia por fila, por transformación y entre filas dentro de la misma declaración DML y evita los interbloqueos. En el caso de varias declaraciones UPDATE en la misma tabla, BigQuery cambia al control de simultaneidad pesimista y pone en cola varias declaraciones UPDATE; además se realizan reintentos de forma automática en caso de conflictos. Las declaraciones DML INSERT y los trabajos de carga se pueden ejecutar de forma independiente y simultánea para agregar contenido a las tablas.

Revertir

Teradata admite dos modos de reversión de sesión: el modo de sesión de ANSI y el modo de sesión de Teradata (SET SESSION CHARACTERISTICS y SET SESSION TRANSACTION), según el modo de reversión que desees. En casos de falla, es posible que la transacción no se revierta.

BigQuery es compatible con la declaración ROLLBACK TRANSACTION. No hay una declaración ABORT en BigQuery.

Límites de bases de datos

Siempre consulta la documentación pública de BigQuery para conocer las cuotas y los límites actuales. Para aumentar las cuotas de los usuarios de gran volumen, comunícate con el equipo de Asistencia de Cloud. En la siguiente tabla, se muestra una comparación de los límites de bases de datos de Teradata y BigQuery.

Límite	Teradata	BigQuery
Tablas por base de datos	Sin restricciones	Sin restricciones
Columnas por tabla	2,048	10,000
Tamaño máximo de fila	1 MB	100 MB
Longitud del nombre de la columna y la tabla	128 caracteres Unicode	16,384 caracteres Unicode
Filas por tabla	Ilimitado	Ilimitado
Longitud máxima de la solicitud de SQL	1 MB	1 MB (extensión máxima sin resolver de la consulta de GoogleSQL) 12 MB (extensión máxima resuelta de la consulta de Google SQL y heredada) Transmisión: 10 MB (límite de tamaño de la solicitud HTTP) 10,000 (máximo de filas por solicitud)
Tamaño máximo de solicitudes y respuestas	7 MB (solicitud) y 16 MB (respuesta)	10 MB (solicitud) y 10 GB (respuesta) o casi sin límite si usas la paginación o la API de Cloud Storage
Cantidad máxima de sesiones simultáneas	120 por motor de análisis (PE)	100 consultas simultáneas (se pueden generar con una reserva de ranura) y 300 solicitudes a la API simultáneas por usuario
Cantidad máxima de cargas (rápidas) simultáneas	30 (5 predeterminadas)	Sin límite de simultaneidad; los trabajos se ponen en cola. 100,000 trabajos de carga por proyecto por día

Guía de traducción de SQL de Teradata

Tipos de datos

Formatos de tipos de Teradata

Tipos de formato de marca de tiempo y fecha

Sintaxis de las consultas

Declaración SELECT

Operadores de comparación

JOIN condiciones

Transmisión y conversión de tipos

Cláusulas QUALIFY, ROWS

Palabra clave NORMALIZE

Funciones

Funciones de agregación

Funciones analíticas de Teradata y BigQuery

Funciones de fecha y hora

Funciones de string

Funciones matemáticas

Sintaxis del DML

Declaración INSERT

Declaración UPDATE

Declaraciones DELETE y TRUNCATE

Declaración MERGE

Variables afectadas por filas

Sintaxis del DDL

Declaración CREATE TABLE

Atributos y opciones de columnas

Tablas temporales

Declaración CREATE VIEW

Declaración CREATE [UNIQUE] INDEX

Indexa en favor del rendimiento

Indexa en favor de la coherencia (UNIQUE, PRIMARY INDEX)

Indexa en favor del bloqueo

Instrucciones de SQL de procedimiento

Declaración CREATE PROCEDURE

Declaración y asignación de variables

Controladores de condiciones de error

Declaraciones y operaciones del cursor

Instrucciones de SQL dinámicas

Instrucciones de flujo de control

Instrucciones de SQL de transacciones y metadatos

Instrucciones de SQL de varias instrucciones y varias líneas

Mensajes y códigos de error

Garantías de coherencia y aislamiento de transacción

Transacciones

Revertir

Límites de bases de datos

Declaración `SELECT`

`JOIN` condiciones

Cláusulas `QUALIFY`, `ROWS`

Palabra clave `NORMALIZE`

Declaración `INSERT`

Declaración `UPDATE`

Declaraciones `DELETE` y `TRUNCATE`

Declaración `MERGE`

Declaración `CREATE TABLE`

Declaración `CREATE VIEW`

Declaración `CREATE [UNIQUE] INDEX`

Declaración `CREATE PROCEDURE`