Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Guida alla traduzione SQL di Teradata

Questo documento descrive in dettaglio le somiglianze e le differenze nella sintassi SQL tra Teradata e BigQuery per aiutarti a pianificare la migrazione. Utilizza la traduzione SQL batch per eseguire la migrazione collettiva degli script SQL o la traduzione SQL interattiva per tradurre query ad hoc.

Tipi di dati

Questa sezione mostra le equivalenze tra i tipi di dati in Teradata e in BigQuery.

Teradata	BigQuery	Note
`INTEGER`	`INT64`
`SMALLINT`	`INT64`
`BYTEINT`	`INT64`
`BIGINT`	`INT64`
`DECIMAL`	`NUMERIC, DECIMAL` `BIGNUMERIC, BIGDECIMAL`	Utilizza il tipo `NUMERIC` (alias `DECIMAL`) di BigQuery quando la scala (cifre dopo il separatore decimale) è <= 9. Utilizza `BIGNUMERIC` di BigQuery (alias `BIGDECIMAL`) quando la scala è > 9. Utilizza i tipi di dati decimali con parametri di BigQuery se devi applicare limiti (vincoli) personalizzati per cifre o scale. Teradata consente di inserire valori di precisione superiore arrotondando il valore memorizzato, ma mantiene l'alta precisione nei calcoli. Ciò può portare a un comportamento di arrotondamento imprevisto rispetto allo standard ANSI.
`FLOAT`	`FLOAT64`
`NUMERIC`	`NUMERIC, DECIMAL` `BIGNUMERIC, BIGDECIMAL`	Utilizza il tipo `NUMERIC` (alias `DECIMAL`) di BigQuery quando la scala (cifre dopo il separatore decimale) è <= 9. Utilizza `BIGNUMERIC` di BigQuery (alias `BIGDECIMAL`) quando la scala è > 9. Utilizza i tipi di dati decimali parametrizzati di BigQuery se devi applicare limiti (vincoli) personalizzati per cifre o scale. Teradata consente di inserire valori di precisione superiore arrotondando il valore memorizzato, ma mantiene l'alta precisione nei calcoli. Ciò può portare a un comportamento di arrotondamento imprevisto rispetto allo standard ANSI.
`NUMBER`	`NUMERIC, DECIMAL` `BIGNUMERIC, BIGDECIMAL`	Utilizza il tipo `NUMERIC` (alias `DECIMAL`) di BigQuery quando la scala (cifre dopo il separatore decimale) è <= 9. Utilizza `BIGNUMERIC` di BigQuery (alias `BIGDECIMAL`) quando la scala è > 9. Utilizza i tipi di dati decimali parametrizzati di BigQuery se devi applicare limiti (vincoli) personalizzati per cifre o scale. Teradata consente di inserire valori di precisione superiore arrotondando il valore memorizzato, ma mantiene l'alta precisione nei calcoli. Ciò può portare a un comportamento di arrotondamento imprevisto rispetto allo standard ANSI.
`REAL`	`FLOAT64`
`CHAR/CHARACTER`	`STRING`	Utilizza il tipo di dati `STRING` con parametri di BigQuery se devi applicare una lunghezza massima dei caratteri.
`VARCHAR`	`STRING`	Utilizza il tipo di dati `STRING` parametrizzato di BigQuery se devi applicare una lunghezza massima dei caratteri.
`CLOB`	`STRING`
`JSON`	`JSON`
`BLOB`	`BYTES`
`BYTE`	`BYTES`
`VARBYTE`	`BYTES`
`DATE`	`DATE`	BigQuery non supporta la formattazione personalizzata simile a quella supportata da Teradata con DataForm in SDF.
`TIME`	`TIME`
`TIME WITH TIME ZONE`	`TIME`	Teradata archivia il tipo di dati `TIME` in UTC e consente di passare un offset da UTC utilizzando la sintassi `WITH TIME ZONE`.Il tipo di dati `TIME` in BigQuery rappresenta un'ora indipendente da qualsiasi data o fuso orario.
`TIMESTAMP`	`TIMESTAMP`	I tipi di dati sia di Teradata che di BigQuery `TIMESTAMP` hanno una precisione di microsecondi (ma Teradata supporta i secondi intercalari, mentre BigQuery no). In genere, i tipi di dati Teradata e BigQuery sono associati a un fuso orario UTC (dettagli).
`TIMESTAMP WITH TIME ZONE`	`TIMESTAMP`	Il tipo `TIMESTAMP` di Teradata può essere impostato su un fuso orario diverso a livello di sistema, per utente o per colonna (utilizzando `WITH TIME ZONE`). Il tipo `TIMESTAMP` di BigQuery presuppone il fuso orario UTC se non lo specifichi esplicitamente. Assicurati di esportare correttamente le informazioni sul fuso orario (non concatenare un valore `DATE` e `TIME` senza informazioni sul fuso orario) in modo che BigQuery possa convertirle durante l'importazione. In alternativa, assicurati di convertire le informazioni sul fuso orario in UTC prima dell'esportazione. BigQuery ha `DATETIME` per un'astrazione tra l'ora civile, che non mostra un fuso orario quando viene restituita, e `TIMESTAMP`, che è un momento preciso nel tempo che mostra sempre il fuso orario UTC.
`ARRAY`	`ARRAY`
`MULTI-DIMENSIONAL ARRAY`	`ARRAY`	In BigQuery, utilizza un array di struct, con ogni struct contenente un campo di tipo `ARRAY` (per maggiori dettagli, consulta la documentazione di BigQuery).
`INTERVAL HOUR`	`INT64`
`INTERVAL MINUTE`	`INT64`
`INTERVAL SECOND`	`INT64`
`INTERVAL DAY`	`INT64`
`INTERVAL MONTH`	`INT64`
`INTERVAL YEAR`	`INT64`
`PERIOD(DATE)`	`DATE`, `DATE`	`PERIOD(DATE)` deve essere convertito in due colonne `DATE` contenenti la data di inizio e la data di fine in modo che possano essere utilizzate con le funzioni finestra.
`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`

Per saperne di più sul cast dei tipi, consulta la sezione successiva.

Formattazione del tipo Teradata

Teradata SQL utilizza un insieme di formati predefiniti per la visualizzazione di espressioni e dati delle colonne e per le conversioni tra tipi di dati. Ad esempio, un tipo di dati PERIOD(DATE) in modalità INTEGERDATE viene formattato come YY/MM/DD per impostazione predefinita. Ti consigliamo di utilizzare la modalità ANSIDATE, se possibile, per garantire la conformità ad ANSI SQL e di cogliere l'occasione per ripulire i formati legacy.

Teradata consente l'applicazione automatica di formati personalizzati utilizzando la clausola FORMAT, senza modificare lo spazio di archiviazione sottostante, come attributo del tipo di dati quando crei una tabella utilizzando DDL o in un'espressione derivata. Ad esempio, una specifica FORMAT 9.99 arrotonda qualsiasi valore FLOAT a due cifre. In BigQuery, questa funzionalità deve essere convertita utilizzando la funzione ROUND().

Questa funzionalità richiede la gestione di casi limite complessi. Ad esempio, quando la clausola FORMAT viene applicata a una colonna NUMERIC, devi tenere conto di regole speciali di arrotondamento e formattazione. Una clausola FORMAT può essere utilizzata per eseguire il cast implicito di un valore epoch INTEGER in un formato DATE. Oppure una specifica FORMAT X(6) su una colonna VARCHAR tronca il valore della colonna, pertanto devi eseguire la conversione in una funzione SUBSTR(). Questo comportamento non è conforme ad ANSI SQL. Pertanto, ti suggeriamo di non eseguire la migrazione dei formati delle colonne a BigQuery.

Se i formati delle colonne sono assolutamente necessari, utilizza le viste o le funzioni definite dall'utente (UDF).

Per informazioni sui formati predefiniti utilizzati da Teradata SQL per ogni tipo di dati, consulta la documentazione sulla formattazione predefinita di Teradata.

Formattazione dei tipi di timestamp e data

La seguente tabella riassume le differenze negli elementi di formattazione di timestamp e date tra Teradata SQL e GoogleSQL.

Formato Teradata	Descrizione di Teradata	BigQuery
`CURRENT_TIMESTAMP CURRENT_TIME`	Le informazioni `TIME` e `TIMESTAMP` in Teradata possono avere informazioni sul fuso orario diverse, definite utilizzando `WITH TIME ZONE`.	Se possibile, utilizza `CURRENT_TIMESTAMP()`, che è formattato in formato ISO. Tuttavia, il formato di output mostra sempre il fuso orario UTC. (Internamente, BigQuery non ha un fuso orario). Tieni presente i seguenti dettagli sulle differenze nel formato ISO. `DATETIME` è formattato in base alle convenzioni del canale di output. Nello strumento a riga di comando BigQuery e nella console BigQuery, viene formattato utilizzando un separatore `T` in base allo standard RFC 3339. Tuttavia, in Python e Java JDBC, viene utilizzato uno spazio come separatore. Se vuoi utilizzare un formato esplicito, utilizza `FORMAT_DATETIME()`, che esegue un cast esplicito di una stringa. Ad esempio, la seguente espressione restituisce sempre un separatore di spazio: `CAST(CURRENT_DATETIME() AS STRING)` Teradata supporta una parola chiave `DEFAULT` nelle colonne `TIME` per impostare l'ora corrente (timestamp); questa non viene utilizzata in BigQuery.
`CURRENT_DATE`	Le date vengono archiviate in Teradata come valori `INT64` utilizzando la seguente formula: `(YEAR - 1900) * 10000 + (MONTH * 100) + DAY` Le date possono essere formattate come numeri interi.	BigQuery ha un formato `DATE` separato che restituisce sempre una data nel formato ISO 8601. `DATE_FROM_UNIX_DATE` non può essere utilizzato perché è basato sul 1970. Teradata supporta una parola chiave `DEFAULT` nelle colonne `DATE` per impostare la data corrente; questa non viene utilizzata in BigQuery.
`CURRENT_DATE-3`	I valori di data sono rappresentati come numeri interi. Teradata supporta gli operatori aritmetici per i tipi di date.	Per i tipi di date, utilizza `DATE_ADD()` o `DATE_SUB()`. BigQuery utilizza operatori aritmetici per i tipi di dati: `INT64`, `NUMERIC` e `FLOAT64`.
`SYS_CALENDAR.CALENDAR`	Teradata fornisce una vista per le operazioni del calendario per andare oltre le operazioni con numeri interi.	Non utilizzato in BigQuery.
`SET SESSION DATEFORM=ANSIDATE`	Imposta il formato della data della sessione o del sistema su ANSI (ISO 8601).	BigQuery utilizza sempre lo standard ISO 8601, quindi assicurati di convertire le date e gli orari di Teradata.

Sintassi delle query

Questa sezione illustra le differenze nella sintassi delle query tra Teradata e BigQuery.

`SELECT` istruzioni

La maggior parte delle istruzioni SELECT di Teradata è compatibile con BigQuery. La tabella seguente contiene un elenco di differenze minori.

Teradata		BigQuery
`SEL`		Converti in `SELECT`. BigQuery non utilizza l'abbreviazione `SEL`.
`SELECT (subquery) AS flag, CASE WHEN flag = 1 THEN ...`		In BigQuery, le colonne non possono fare riferimento all'output di altre colonne definite nello stesso elenco di selezione. Preferisci spostare una sottoquery in una clausola `WITH`. `WITH flags AS ( subquery ), SELECT CASE WHEN flags.flag = 1 THEN ...`
`SELECT * FROM table WHERE A LIKE ANY ('string1', 'string2')`		BigQuery non utilizza il predicato logico `ANY`. La stessa funzionalità può essere ottenuta utilizzando più operatori `OR`: `SELECT * FROM table WHERE col LIKE 'string1' OR col LIKE 'string2'` In questo caso, anche il confronto delle stringhe è diverso. Consulta la sezione Operatori di confronto.
`SELECT TOP 10 * FROM table`		BigQuery utilizza `LIMIT` alla fine di una query anziché `TOP n` dopo la parola chiave `SELECT`.

Operatori di confronto

La tabella seguente mostra gli operatori di confronto Teradata specifici di Teradata che devono essere convertiti negli operatori conformi ad ANSI SQL:2011 utilizzati in BigQuery.

Per informazioni sugli operatori in BigQuery, consulta la sezione Operatori della documentazione di BigQuery.

Teradata	BigQuery	Note
`exp EQ exp2` `exp IN (exp2, exp3)`	`exp = exp2` `exp IN (exp2, exp3)` Per mantenere la semantica non ANSI per `NOT CASESPECIFIC`, puoi utilizzare `RTRIM(UPPER(exp)) = RTRIM(UPPER(exp2))`	Quando si confrontano le stringhe per verificarne l'uguaglianza, Teradata potrebbe ignorare gli spazi vuoti finali, mentre BigQuery li considera parte della stringa. Ad esempio, `'xyz'=' xyz'` è `TRUE` in Teradata, ma `FALSE` in BigQuery. Teradata fornisce anche un attributo di colonna `NOT CASESPECIFIC` che indica a Teradata di ignorare la distinzione tra maiuscole e minuscole quando confronta due stringhe. BigQuery distingue sempre tra maiuscole e minuscole quando confronta le stringhe. Ad esempio, `'xYz' = 'xyz'` è `TRUE` in Teradata, ma `FALSE` in 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` condizioni

BigQuery e Teradata supportano le stesse condizioni JOIN, ON e USING. La tabella seguente contiene un elenco di differenze minori.

Teradata	BigQuery	Note
`FROM A JOIN B ON A.date > B.start_date AND A.date < B.end_date`	`FROM A LEFT OUTER JOIN B ON A.date > B.start_date AND A.date < B.end_date`	BigQuery supporta le clausole di disuguaglianza `JOIN` per tutti gli inner join o se viene fornita almeno una condizione di uguaglianza (=). Ma non solo una condizione di disuguaglianza (= e <) in un `OUTER JOIN`. Questi costrutti vengono talvolta utilizzati per eseguire query su intervalli di date o numeri interi. BigQuery impedisce agli utenti di creare inavvertitamente cross join di grandi dimensioni.
`FROM A, B ON A.id = B.id`	`FROM A JOIN B ON A.id = B.id`	L'utilizzo di una virgola tra le tabelle in Teradata equivale a un `INNER JOIN`, mentre in BigQuery equivale a un `CROSS JOIN` (prodotto cartesiano). Poiché la virgola in SQL precedente di BigQuery viene trattata come `UNION`, ti consigliamo di rendere esplicita l'operazione per evitare confusione.
`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))`	Nessuna differenza per le funzioni scalari (costanti).
`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 impedisce agli utenti di utilizzare subquery, subquery correlate o aggregazioni nei predicati di join. In questo modo, BigQuery può parallelizzare le query.

Conversione e casting dei tipi

BigQuery ha tipi di dati meno numerosi ma più ampi rispetto a Teradata, il che richiede che BigQuery sia più rigoroso nel casting.

Teradata	BigQuery	Note
`exp EQ exp2` `exp IN (exp2, exp3)`	`exp = exp2` `exp IN (exp2, exp3)` Per mantenere la semantica non ANSI per `NOT CASESPECIFIC`, puoi utilizzare `RTRIM(UPPER(exp)) = RTRIM(UPPER(exp2))`	Quando si confrontano le stringhe per verificarne l'uguaglianza, Teradata potrebbe ignorare gli spazi vuoti finali, mentre BigQuery li considera parte della stringa. Ad esempio, `'xyz'=' xyz'` è `TRUE` in Teradata, ma `FALSE` in BigQuery. Teradata fornisce anche un attributo di colonna `NOT CASESPECIFIC` che indica a Teradata di ignorare la distinzione tra maiuscole e minuscole quando confronta due stringhe. BigQuery distingue sempre tra maiuscole e minuscole quando confronta le stringhe. Ad esempio, `'xYz' = 'xyz'` è `TRUE` in Teradata, ma `FALSE` in BigQuery.
`CAST(long_varchar_column AS CHAR(6))`	`LPAD(long_varchar_column, 6)`	Il casting di una colonna di caratteri in Teradata viene talvolta utilizzato come modo non standard e non ottimale per creare una sottostringa con spaziatura interna.
`CAST(92617 AS TIME) 92617 (FORMAT '99:99:99')`	`PARSE_TIME("%k%M%S", CAST(92617 AS STRING))`	Teradata esegue molte più conversioni di tipo implicite e arrotondamenti rispetto a BigQuery, che è generalmente più rigoroso e applica gli standard ANSI. (Questo esempio restituisce 09:26:17)
`CAST(48.5 (FORMAT 'zz') AS FLOAT)`	`CAST(SUBSTR(CAST(48.5 AS STRING), 0, 2) AS FLOAT64)`	I tipi di dati numerici e in virgola mobile possono richiedere regole di arrotondamento speciali se applicati con formati come le valute. (questo esempio restituisce 48)

Trasmetti `FLOAT`/`DECIMAL` su `INT`

Se Teradata utilizza gli algoritmi Gaussian e Banker per arrotondare i numeri, utilizza ROUND_HALF_EVEN RoundingMode in BigQuery:

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

Trasmetti `STRING` su `NUMERIC` o `BIGNUMERIC`

Quando esegui la conversione da STRING a valori numerici, utilizza il tipo di dati corretto, NUMERIC o BIGNUMERIC, in base al numero di cifre decimali nel valore STRING.

Per saperne di più sulla precisione e sulla scala numeriche supportate in BigQuery, consulta Tipi decimali.

Consulta anche Operatori di confronto e Formati delle colonne. Sia i confronti che la formattazione delle colonne possono comportarsi come cast di tipo.

`QUALIFY`, `ROWS` clausole

La clausola QUALIFY in Teradata consente di filtrare i risultati per le funzioni finestra. In alternativa, per la stessa attività è possibile utilizzare una fraseROWS. Queste funzionano in modo simile a una condizione HAVING per una clausola GROUP, limitando l'output di quelle che in BigQuery sono chiamate funzioni finestra.

Teradata	BigQuery
`SELECT col1, col2 FROM table QUALIFY ROW_NUMBER() OVER (PARTITION BY col1 ORDER BY col2) = 1;`	La clausola `QUALIFY` di Teradata con una funzione finestra come `ROW_NUMBER()`, `SUM()`, `COUNT()` e con `OVER PARTITION BY` è espressa in BigQuery come clausola `WHERE` su una sottoquery che contiene un valore di analisi. Utilizzando `ROW_NUMBER()`: `SELECT col1, col2 FROM ( SELECT col1, col2, ROW_NUMBER() OVER (PARTITION BY col1 ORDER BY col2) RN FROM table ) WHERE RN = 1;` Utilizzando `ARRAY_AGG`, che supporta partizioni più grandi: `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);` In BigQuery, sia `RANGE` che `ROWS` possono essere utilizzati nella clausola della frame della finestra. Tuttavia, le clausole finestra possono essere utilizzate solo con funzioni finestra come `AVG()`, non con funzioni di numerazione come `ROW_NUMBER()`.
`SELECT col1, col2 FROM table QUALIFY ROW_NUMBER() OVER (PARTITION BY col1 ORDER BY col2) = 1;`	`SELECT col1, col2 FROM Dataset-name.table QUALIFY row_number() OVER (PARTITION BY upper(a.col1) ORDER BY upper(a.col2)) = 1`

`NORMALIZE` parola chiave

Teradata fornisce la parola chiave NORMALIZE per le clausole SELECT per unire periodi o intervalli sovrapposti in un unico periodo o intervallo che comprende tutti i singoli valori del periodo.

BigQuery non supporta il tipo PERIOD, pertanto qualsiasi colonna di tipo PERIOD in Teradata deve essere inserita in BigQuery come due campi DATE o DATETIME separati che corrispondono all'inizio e alla fine del periodo.

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;

Funzioni

Le sezioni seguenti elencano le mappature tra le funzioni Teradata e gli equivalenti BigQuery.

Funzioni di aggregazione

La tabella seguente mappa le funzioni di aggregazione, aggregazione statistica e aggregazione approssimata comuni di Teradata ai loro equivalenti BigQuery. BigQuery offre le seguenti funzioni aggregate aggiuntive:

Teradata	BigQuery
`AVG`	`AVG` Nota: BigQuery fornisce risultati approssimativi quando calcola la media dei valori `INT`.
`BITAND`	`BIT_AND`
`BITNOT`	Operatore NOT bit per bit (`~`)
`BITOR`	`BIT_OR`
`BITXOR`	`BIT_XOR`
`CORR`	`CORR`
`COUNT`	`COUNT`
`COVAR_POP`	`COVAR_POP`
`COVAR_SAMP`	`COVAR_SAMP`
`MAX`	`MAX`
`MIN`	`MIN`
`REGR_AVGX`	`AVG( IF(dep_var_expression is NULL OR ind_var_expression is NULL, NULL, ind_var_expression) )`
`REGR_AVGY`	`AVG( IF(dep_var_expression is NULL OR ind_var_expression is NULL, NULL, dep_var_expression) )`
`REGR_COUNT`	`SUM( IF(dep_var_expression is NULL OR ind_var_expression is NULL, NULL, 1) )`
`REGR_INTERCEPT`	`AVG(dep_var_expression) - AVG(ind_var_expression) * (COVAR_SAMP(ind_var_expression, dep_var_expression) / VARIANCE(ind_var_expression))`
`REGR_R2`	`(COUNT(dep_var_expression)* SUM(ind_var_expression * dep_var_expression) - SUM(dep_var_expression) * SUM(ind_var_expression)) / SQRT( (COUNT(ind_var_expression)* SUM(POWER(ind_var_expression, 2))* POWER(SUM(ind_var_expression),2))* (COUNT(dep_var_expression)* SUM(POWER(dep_var_expression, 2))* POWER(SUM(dep_var_expression), 2)))`
`REGR_SLOPE`	`- COVAR_SAMP(ind_var_expression, dep_var_expression) / VARIANCE(ind_var_expression)`
`REGR_SXX`	`SUM(POWER(ind_var_expression, 2)) - COUNT(ind_var_expression) * POWER(AVG(ind_var_expression),2)`
`REGR_SXY`	`SUM(ind_var_expression * dep_var_expression) - COUNT(ind_var_expression) * AVG(ind_var_expression) * AVG(dep_var_expression)`
`REGR_SYY`	`SUM(POWER(dep_var_expression, 2)) - COUNT(dep_var_expression) * POWER(AVG(dep_var_expression),2)`
`SKEW`	Funzione definita dall'utente personalizzata.
`STDDEV_POP`	`STDDEV_POP`
`STDDEV_SAMP`	`STDDEV_SAMP, STDDEV`
`SUM`	`SUM`
`VAR_POP`	`VAR_POP`
`VAR_SAMP`	`VAR_SAMP, VARIANCE`

Funzioni analitiche e funzioni finestra

La tabella seguente mappa le funzioni analitiche e di aggregazione analitica comuni di Teradata alle funzione finestra equivalenti di BigQuery. BigQuery offre le seguenti funzioni aggiuntive:

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

Funzioni di data/ora

La tabella seguente mappa le funzioni di data/ora comuni di Teradata ai relativi equivalenti di BigQuery. BigQuery offre le seguenti funzioni di data/ora aggiuntive:

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: questa funzione supporta sia le espressioni di input `DATE` che `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`

Funzioni di stringa

La seguente tabella mappa le funzioni di stringa di Teradata ai relativi equivalenti di BigQuery. BigQuery offre le seguenti funzioni stringa aggiuntive:

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`	Funzione definita dall'utente personalizzata.
`CSVLD`	Funzione definita dall'utente personalizzata.
`FORMAT`	`FORMAT`
`INDEX`	`STRPOS(string, substring)`
`INITCAP`	`INITCAP`
`INSTR`	Funzione definita dall'utente personalizzata.
`LEFT`	`SUBSTR(source_string, 1, length)`
`LENGTH`	`LENGTH`
`LOWER`	`LOWER`
`LPAD`	`LPAD`
`LTRIM`	`LTRIM`
`NGRAM`	Funzione definita dall'utente personalizzata.
`NVP`	Funzione definita dall'utente personalizzata.
`OREPLACE`	`REPLACE`
`OTRANSLATE`	Funzione definita dall'utente personalizzata.
`POSITION`	`STRPOS(string, substring)`
`REGEXP_INSTR`	`STRPOS(source_string, REGEXP_EXTRACT(source_string, regexp_string))` Nota: restituisce la prima occorrenza.
`REGEXP_REPLACE`	`REGEXP_REPLACE`
`REGEXP_SIMILAR`	`IF(REGEXP_CONTAINS,1,0)`
`REGEXP_SUBSTR`	`REGEXP_EXTRACT, REGEXP_EXTRACT_ALL`
`REGEXP_SPLIT_TO_TABLE`	Funzione definita dall'utente personalizzata.
`REVERSE`	`REVERSE`
`RIGHT`	`SUBSTR(source_string, -1, length)`
`RPAD`	`RPAD`
`RTRIM`	`RTRIM`
`STRTOK` Il delimitatore predefinito è un carattere di spazio.	`SPLIT(instring, delimiter)[ORDINAL(tokennum)]` Nota: l'intero argomento della stringa delimiter viene utilizzato come un singolo delimitatore. Il delimitatore predefinito è una virgola.
`STRTOK_SPLIT_TO_TABLE`	Funzione definita dall'utente personalizzata
`SUBSTRING`, `SUBSTR`	`SUBSTR`
`TRIM`	`TRIM`
`UPPER`	`UPPER`

Funzioni matematiche

La seguente tabella mappa le funzioni matematiche di Teradata ai relativi equivalenti di BigQuery. BigQuery offre le seguenti funzioni matematiche aggiuntive:

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

Funzioni di arrotondamento

Se Teradata utilizza gli algoritmi Gaussian e Banker per arrotondare i numeri, utilizza ROUND_HALF_EVEN RoundingMode in BigQuery:


-- Teradata syntax
round(3.45,1)

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

Sintassi DML

Questa sezione illustra le differenze nella sintassi del linguaggio di gestione dei dati tra Teradata e BigQuery.

`INSERT` istruzioni

La maggior parte delle istruzioni INSERT di Teradata è compatibile con BigQuery. La tabella seguente mostra le eccezioni.

Gli script DML in BigQuery hanno una semantica di coerenza leggermente diversa rispetto alle istruzioni equivalenti in Teradata. Per una panoramica dell'isolamento degli snapshot e della gestione di sessioni e transazioni, consulta la sezione CREATE INDEX in un'altra parte di questo documento.

Teradata BigQuery

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

Teradata offre una parola chiave DEFAULT per le colonne non nullable.

Nota: in BigQuery, l'omissione dei nomi delle colonne nell'istruzione INSERT funziona solo se i valori di tutte le colonne della tabella di destinazione sono inclusi in ordine crescente in base alle loro posizioni ordinali.

Teradata	BigQuery
`INSERT INTO table VALUES (...);`	`INSERT INTO table (...) VALUES (...);` Teradata offre una parola chiave `DEFAULT` per le colonne non nullable. Nota: in BigQuery, l'omissione dei nomi delle colonne nell'istruzione `INSERT` funziona solo se i valori di tutte le colonne della tabella di destinazione sono inclusi in ordine crescente in base alle loro posizioni ordinali.
`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 ha un concetto di richiesta con più istruzioni (MSR), che invia più istruzioni `INSERT` alla volta. In BigQuery, questa operazione non è consigliata a causa del confine di transazione implicito tra le istruzioni. Utilizza invece multi-value `INSERT`. BigQuery consente istruzioni `INSERT` simultanee, ma potrebbe mettere in coda `UPDATE`. Per migliorare le prestazioni, valuta i seguenti approcci: Combina più righe in un'unica istruzione `INSERT`, anziché una riga per operazione `INSERT`. Combina più istruzioni DML (tra cui `INSERT`) utilizzando un'istruzione `MERGE`. Utilizza `CREATE TABLE ... AS SELECT` per creare e compilare nuove tabelle anziché `UPDATE` o `DELETE`, in particolare quando esegui query su campi partizionati o rollback o ripristino.


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 ha un concetto di richiesta con più istruzioni (MSR), che invia più istruzioni INSERT alla volta. In BigQuery, questa operazione non è consigliata a causa del confine di transazione implicito tra le istruzioni. Utilizza invece multi-value INSERT.

BigQuery consente istruzioni INSERT simultanee, ma potrebbe mettere in coda UPDATE. Per migliorare le prestazioni, valuta i seguenti approcci:

Combina più righe in un'unica istruzione INSERT, anziché una riga per operazione INSERT.
Combina più istruzioni DML (tra cui INSERT) utilizzando un'istruzione MERGE.
Utilizza CREATE TABLE ... AS SELECT per creare e compilare nuove tabelle anziché UPDATE o DELETE, in particolare quando esegui query su campi partizionati o rollback o ripristino.

`UPDATE` istruzioni

La maggior parte delle istruzioni Teradata UPDATE è compatibile con BigQuery, ad eccezione dei seguenti elementi:

Quando utilizzi una clausola FROM, l'ordine delle clausole FROM e SET è invertito in Teradata e BigQuery.
In GoogleSQL, ogni istruzione UPDATE deve includere la parola chiave WHERE, seguita da una condizione. Per aggiornare tutte le righe della tabella, utilizza WHERE true.

Come best practice, devi raggruppare più mutazioni DML anziché singole istruzioni UPDATE e INSERT. Gli script DML in BigQuery hanno una semantica di coerenza leggermente diversa rispetto alle istruzioni equivalenti in Teradata. Per una panoramica sull'isolamento degli snapshot e sulla gestione di sessioni e transazioni, consulta la sezione CREATE INDEX in un'altra parte di questo documento.

La tabella seguente mostra le istruzioni Teradata UPDATE e le istruzioni BigQuery che eseguono le stesse attività.

Per saperne di più su UPDATE in BigQuery, consulta gli esempi di UPDATE di BigQuery nella documentazione di DML.

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

`DELETE` e `TRUNCATE` istruzioni

Le istruzioni DELETE e TRUNCATE sono entrambe modi supportati per rimuovere righe da una tabella senza influire sullo schema o sugli indici della tabella. TRUNCATE elimina tutti i dati, mentre DELETE rimuove le righe selezionate dalla tabella.

In BigQuery, l'istruzione DELETE deve avere una clausola WHERE. Per eliminare tutte le righe della tabella (troncare), utilizza WHERE true. Per velocizzare le operazioni di troncamento per tabelle molto grandi, ti consigliamo di utilizzare l'istruzione CREATE OR REPLACE TABLE ... AS SELECT, utilizzando un LIMIT 0 sulla stessa tabella per sostituirla. Tuttavia, assicurati di aggiungere manualmente le informazioni di partizionamento e clustering quando lo utilizzi.

Teradata esegue il vacuum delle righe eliminate in un secondo momento. Ciò significa che le operazioni DELETE sono inizialmente più veloci rispetto a BigQuery, ma richiedono risorse in un secondo momento, in particolare le operazioni DELETE su larga scala che interessano la maggior parte di una tabella. Per utilizzare un approccio simile in BigQuery, ti suggeriamo di ridurre il numero di operazioni DELETE, ad esempio copiando le righe da non eliminare in una nuova tabella. In alternativa, puoi rimuovere intere partizioni. Entrambe le opzioni sono progettate per essere operazioni più veloci rispetto alle mutazioni DML atomiche.

Per saperne di più su DELETE in BigQuery, consulta gli esempi di DELETE nella documentazione di 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;`	La sostituzione dei contenuti di una tabella con l'output della query equivale a una transazione. Puoi farlo con un'operazione di query o di copia. Utilizzando un'operazione di query: `bq query --replace --destination_table table_A 'SELECT * FROM table_B';` Utilizzando un'operazione di copia: `bq cp -f table_A table_B`
`DELETE database.table ALL;`	`DELETE FROM table WHERE TRUE;` In alternativa, per tabelle molto grandi, un modo più rapido: `CREATE OR REPLACE table AS SELECT * FROM table LIMIT 0;`

`MERGE` istruzioni

L'istruzione MERGE può combinare le operazioni INSERT, UPDATE e DELETE in un'unica istruzione "upsert" ed eseguire le operazioni in modo atomico. L'operazione MERGE deve corrispondere al massimo a una riga di origine per ogni riga di destinazione. Sia BigQuery che Teradata seguono la sintassi ANSI.

L'operazione MERGE di Teradata è limitata alla corrispondenza delle chiavi primarie all'interno di un processore del modulo di accesso (AMP). Al contrario, BigQuery non ha limiti di dimensioni o colonne per le operazioni MERGE, pertanto l'utilizzo di MERGE è un'ottimizzazione utile. Tuttavia, se MERGE è principalmente un'eliminazione di grandi dimensioni, consulta le ottimizzazioni per DELETE altrove in questo documento.

Gli script DML in BigQuery hanno una semantica di coerenza leggermente diversa rispetto alle istruzioni equivalenti in Teradata. Ad esempio, le tabelle SET di Teradata in modalità sessione potrebbero ignorare i duplicati durante un'operazione MERGE. Per una panoramica sulla gestione delle tabelle MULTISET e SET, sull'isolamento degli snapshot e sulla gestione di sessioni e transazioni, consulta la sezione CREATE INDEX in un'altra parte di questo documento.

Variabili relative alle righe interessate

In Teradata, la variabile ACTIVITY_COUNT è un'estensione SQL ANSI di Teradata compilata con il numero di righe interessate da un'istruzione DML.

La variabile di sistema @@row_count nella funzionalità di scripting ha una funzionalità simile. In BigQuery è più comune controllare il valore restituito numDmlAffectedRows nei log di controllo o nelle viste INFORMATION_SCHEMA.

Sintassi DDL

Questa sezione illustra le differenze nella sintassi del linguaggio di definizione dei dati tra Teradata e BigQuery.

`CREATE TABLE` istruzioni

La maggior parte delle istruzioni CREATE TABLE di Teradata è compatibile con BigQuery, ad eccezione dei seguenti elementi di sintassi, che non vengono utilizzati in BigQuery:

MULTISET. Consulta la sezione CREATE INDEX.
VOLATILE. Consulta la sezione Tabelle temporanee.
[NO] FALLBACK. Consulta la sezione Rollback.
[NO] BEFORE JOURNAL, [NO] AFTER JOURNAL
CHECKSUM = DEFAULT | val
DEFAULT MERGEBLOCKRATIO
PRIMARY INDEX (col, ...). Consulta la sezione CREATE INDEX.
UNIQUE PRIMARY INDEX. Consulta la sezione CREATE INDEX.
CONSTRAINT
DEFAULT
IDENTITY

Per saperne di più su CREATE TABLE in BigQuery, consulta gli esempi di CREATE BigQuery nella documentazione di DML.

Opzioni e attributi delle colonne

Le seguenti specifiche di colonna per l'istruzione CREATE TABLE non vengono utilizzate in BigQuery:

FORMAT 'format'. Consulta la sezione sulla formattazione dei tipi di Teradata.
CHARACTER SET name. BigQuery utilizza sempre la codifica UTF-8.
[NOT] CASESPECIFIC
COMPRESS val | (val, ...)

Teradata estende lo standard ANSI con un'opzione di colonna TITLE. Questa funzionalità può essere implementata in modo simile in BigQuery utilizzando la descrizione della colonna, come mostrato nella tabella seguente. Tieni presente che questa opzione non è disponibile per le viste.

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

Tabelle temporanee

Teradata supporta le tabelle volatili, che vengono spesso utilizzate per archiviare i risultati intermedi negli script. Esistono diversi modi per ottenere un risultato simile alle tabelle volatili in BigQuery:

CREATE TEMPORARY TABLE può essere utilizzato negli script ed è valido per tutta la durata dello script. Se la tabella deve esistere oltre uno script, puoi utilizzare le altre opzioni di questo elenco.
TTL del set di dati: crea un set di dati con una durata (TTL) breve (ad esempio 1 ora) in modo che tutte le tabelle create nel set di dati siano effettivamente temporanee, poiché non persisteranno oltre la durata del set di dati. Puoi aggiungere il prefisso temp a tutti i nomi delle tabelle in questo set di dati per indicare chiaramente che le tabelle sono temporanee.
TTL della tabella: crea una tabella con una durata (TTL) breve specifica per la tabella utilizzando istruzioni DDL simili alle seguenti:
```
CREATE TABLE temp.name (col1, col2, ...)
OPTIONS(expiration_timestamp=TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL 1 HOUR));
```
Clausola WITH: se è necessaria una tabella temporanea solo all'interno dello stesso blocco, utilizza un risultato temporaneo utilizzando un'istruzione o una subquery WITH. Questa è l'opzione più efficiente.

Un pattern utilizzato di frequente negli script Teradata (BTEQ) è creare una tabella permanente, inserire un valore, utilizzarla come tabella temporanea nelle istruzioni in corso e poi eliminarla o troncarla. In effetti, questo utilizza la tabella come variabile costante (un semaforo). Questo approccio non è efficiente in BigQuery e consigliamo di utilizzare variabili reali in Scripting o di utilizzare CREATE OR REPLACE con la sintassi di query AS SELECT per creare una tabella che contiene già valori.

`CREATE VIEW` istruzioni

La seguente tabella mostra gli equivalenti tra Teradata e BigQuery per l'istruzione CREATE VIEW. Le clausole per il blocco delle tabelle, come LOCKING ROW FOR ACCESS, non sono necessarie in BigQuery.

Teradata	BigQuery	Note
`CREATE VIEW view_name AS SELECT ...`	`CREATE VIEW view_name AS SELECT ...`
`REPLACE VIEW view_name AS SELECT ...`	`CREATE OR REPLACE VIEW view_name AS SELECT ...`
Non supportata	`CREATE VIEW IF NOT EXISTS OPTIONS(view_option_list) AS SELECT ...`	Crea una nuova vista solo se non esiste già nel set di dati specificato.

`CREATE [UNIQUE] INDEX` istruzioni

Teradata richiede indici per tutte le tabelle e soluzioni alternative speciali come tabelle MULTISET e tabelle NoPI per funzionare con dati non univoci o non indicizzati.

BigQuery non richiede indici. Questa sezione descrive gli approcci in BigQuery per creare funzionalità simili a quelle degli indici utilizzati in Teradata, laddove esiste un'effettiva esigenza di logica di business.

Indicizzazione per le prestazioni

Poiché si tratta di un database orientato alle colonne con ottimizzazione delle query e dello spazio di archiviazione, BigQuery non richiede indici espliciti. BigQuery offre funzionalità come il partizionamento e il clustering, nonché i campi nidificati, che possono aumentare l'efficienza e le prestazioni delle query ottimizzando il modo in cui i dati vengono archiviati.

Teradata non supporta le viste materializzate. Tuttavia, offre indici di join utilizzando l'istruzione CREATE JOIN INDEX, che materializza essenzialmente i dati necessari per un join. BigQuery non ha bisogno di indici materializzati per accelerare le prestazioni, così come non ha bisogno di spazio di spool dedicato per i join.

Per altri casi di ottimizzazione, è possibile utilizzare le viste materializzate.

Indicizzazione per garantire la coerenza (UNIQUE, PRIMARY INDEX)

In Teradata, è possibile utilizzare un indice univoco per impedire righe con chiavi non univoche in una tabella. Se un processo tenta di inserire o aggiornare dati con un valore già presente nell'indice, l'operazione non va a buon fine con una violazione dell'indice (tabelle MULTISET) o lo ignora silenziosamente (tabelle SET).

Poiché BigQuery non fornisce indici espliciti, è possibile utilizzare un'istruzione MERGE per inserire solo record univoci in una tabella di destinazione da una tabella di gestione temporanea, ignorando i record duplicati. Tuttavia, non è possibile impedire a un utente con autorizzazioni di modifica di inserire un record duplicato, perché BigQuery non si blocca mai durante le operazioni INSERT. Per generare un errore per i record duplicati in BigQuery, puoi utilizzare un'istruzione MERGE da una tabella di gestione temporanea, come mostrato nell'esempio seguente.

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

Più spesso, gli utenti preferiscono rimuovere i duplicati in modo indipendente per trovare errori nei sistemi downstream.
BigQuery non supporta le colonne DEFAULT e IDENTITY (sequenze).

Indicizzazione per ottenere il blocco

Teradata fornisce risorse nel processore del modulo di accesso (AMP); le query possono utilizzare risorse all-AMP, single-AMP o group-AMP. Le istruzioni DDL sono tutte AMP e quindi simili a un blocco DDL globale. BigQuery non dispone di un meccanismo di blocco di questo tipo e può eseguire query e istruzioni INSERT contemporanee fino alla tua quota; solo le istruzioni DML UPDATE contemporanee hanno determinate implicazioni di contemporaneità: le operazioni UPDATE sulla stessa partizione vengono messe in coda per garantire l'isolamento degli snapshot, quindi non è necessario bloccare per impedire letture fantasma o aggiornamenti persi.

A causa di queste differenze, i seguenti elementi Teradata non vengono utilizzati in BigQuery:

ON COMMIT DELETE ROWS;
ON COMMIT PRESERVE ROWS;

Istruzioni SQL procedurali

Questa sezione descrive come convertire le istruzioni SQL procedurali utilizzate nelle stored procedure, nelle funzioni e nei trigger da Teradata a script, procedure o funzioni definite dall'utente (UDF) di BigQuery. Tutte queste informazioni sono disponibili per gli amministratori di sistema, che possono controllarle utilizzando le visualizzazioni INFORMATION_SCHEMA.

`CREATE PROCEDURE` istruzioni

Le stored procedure sono supportate nell'ambito dello scripting di BigQuery.

In BigQuery, gli script si riferiscono a qualsiasi utilizzo di istruzioni di controllo, mentre le procedure sono script denominati (con argomenti, se necessario) che possono essere chiamati da altri script e archiviati in modo permanente, se necessario. Una funzione definita dall'utente (UDF) può anche essere scritta in JavaScript.

Teradata	BigQuery
`CREATE PROCEDURE`	`CREATE PROCEDURE` se è richiesto un nome, altrimenti utilizza la versione in linea con `BEGIN` o su una singola riga con `CREATE TEMP FUNCTION`.
`REPLACE PROCEDURE`	`CREATE OR REPLACE PROCEDURE`
`CALL`	`CALL`

Le sezioni seguenti descrivono i modi per convertire le istruzioni procedurali Teradata esistenti in istruzioni di scripting BigQuery con funzionalità simili.

Dichiarazione e assegnazione di variabili

Le variabili BigQuery sono valide per tutta la durata dello script.

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

Gestori delle condizioni di errore

Teradata utilizza gestori sui codici di stato nelle procedure per il controllo degli errori. In BigQuery, la gestione degli errori è una funzionalità principale del flusso di controllo principale, simile a ciò che altri linguaggi forniscono con i blocchi 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;`	I gestori di eccezioni che si attivano per determinate condizioni di errore non vengono utilizzati da BigQuery. Ti consigliamo di utilizzare le istruzioni `ASSERT` in cui le condizioni di uscita vengono utilizzate per i controlli preliminari o il debug, perché sono conformi ad ANSI SQL:2011.

La variabile SQLSTATE in Teradata è simile alla variabile di sistema @@error in BigQuery. In BigQuery, è più comune esaminare gli errori utilizzando l'audit logging o le viste INFORMATION_SCHEMA.

Dichiarazioni e operazioni del cursore

Poiché BigQuery non supporta cursori o sessioni, le seguenti istruzioni non vengono utilizzate in 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;

Istruzioni SQL dinamiche

La funzionalità di scripting in BigQuery supporta istruzioni SQL dinamiche come quelle mostrate nella tabella seguente.

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

Le seguenti istruzioni SQL dinamiche non vengono utilizzate in BigQuery:

PREPARE stmt_id FROM sql_str;

Istruzioni di flusso di controllo

La funzionalità di scripting in BigQuery supporta istruzioni di controllo del flusso come quelle mostrate nella tabella seguente.

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;`	I costrutti di blocchi in stile GOTO non vengono utilizzati in BigQuery. Ti consigliamo di riscriverle come funzioni definite dall'utente (UDF) o di utilizzare le istruzioni `ASSERT` dove vengono utilizzate per la gestione degli errori.
`REPEAT stmts UNTIL condition END REPEAT;`	`WHILE condition DO stmts END WHILE`
`LEAVE outer_proc_label;`	`LEAVE` non viene utilizzato per i blocchi in stile GOTO, ma come sinonimo di `BREAK` per uscire da un ciclo `WHILE`.
`LEAVE label;`	`LEAVE` non viene utilizzato per i blocchi in stile GOTO, ma come sinonimo di `BREAK` per uscire da un ciclo `WHILE`.
`WITH RECURSIVE temp_table AS ( ... );`	Le query ricorsive (note anche come espressioni di tabella comuni (CTE) ricorsive) non vengono utilizzate in BigQuery. Possono essere riscritte utilizzando array di `UNION ALL`.

Le seguenti istruzioni di controllo del flusso non vengono utilizzate in BigQuery perché BigQuery non utilizza cursori o sessioni:

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

Istruzioni SQL per metadati e transazioni

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 stessa query è valida per ottenere informazioni sulle colonne per le viste. Per saperne di più, consulta la visualizzazione delle colonne in BigQuery `INFORMATION_SCHEMA`.
`SELECT * FROM dbc.tables WHERE tablekind = 'T';` (Vista DBC Teradata)	`SELECT * EXCEPT(is_typed) FROM mydataset.INFORMATION_SCHEMA.TABLES;` Per saperne di più, consulta Introduzione a BigQuery `INFORMATION_SCHEMA`.
`HELP STATISTICS table_name;`	`APPROX_COUNT_DISTINCT(col)`
`COLLECT STATS USING SAMPLE ON table_name column (...);`	Non utilizzato in BigQuery.
`LOCKING TABLE table_name FOR EXCLUSIVE;`	BigQuery utilizza sempre l'isolamento degli snapshot. Per maggiori dettagli, consulta Garanzie di coerenza in un'altra sezione di questo documento.
`SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL ...`	BigQuery utilizza sempre l'isolamento degli snapshot. Per maggiori dettagli, consulta la sezione Garanzie di coerenza più avanti in questo documento.
`BEGIN TRANSACTION; SELECT ... END TRANSACTION;`	BigQuery utilizza sempre l'isolamento degli snapshot. Per maggiori dettagli, consulta Garanzie di coerenza più avanti in questo documento.
`EXPLAIN ...`	Non utilizzato in BigQuery. Funzionalità simili sono la spiegazione del piano di query nell'interfaccia utente web di BigQuery e l'allocazione degli slot visibile nelle visualizzazioni `INFORMATION_SCHEMA` e nell'audit logging in Cloud Monitoring.
`BEGIN TRANSACTION; SELECT ... END TRANSACTION;`	`BEGIN BEGIN TRANSACTION; COMMIT TRANSACTION; EXCEPTION WHEN ERROR THEN -- Roll back the transaction inside the exception handler. SELECT @@error.message; ROLLBACK TRANSACTION; END;`

Istruzioni SQL con più istruzioni e più righe

Sia Teradata che BigQuery supportano le transazioni (sessioni) e, di conseguenza, le istruzioni separate da punti e virgola che vengono eseguite insieme in modo coerente. Per saperne di più, consulta Transazioni con più istruzioni.

Codici e messaggi di errore

I codici di errore di Teradata e BigQuery sono diversi. Fornendo un'API REST, BigQuery si basa principalmente sui codici di stato HTTP oltre a messaggi di errore dettagliati.

Se la logica dell'applicazione attualmente rileva i seguenti errori, prova a eliminare l'origine dell'errore, perché BigQuery non restituirà gli stessi codici di errore.

SQLSTATE = '02000': "Riga non trovata"
SQLSTATE = '21000': "Violazione della cardinalità (indice univoco)"
SQLSTATE = '22000': "Violazione dei dati (tipo di dati)"
SQLSTATE = '23000': "Violazione del vincolo"

In BigQuery, è più comune utilizzare le viste INFORMATION_SCHEMA o l'audit logging per eseguire il drill-down degli errori.

Per informazioni su come gestire gli errori nello scripting, consulta le sezioni seguenti.

Garanzie di coerenza e isolamento delle transazioni

Sia Teradata che BigQuery sono atomici, ovvero conformi ad ACID a livello di singola mutazione su più righe. Ad esempio, un'operazione MERGE è completamente atomica, anche con più valori inseriti e aggiornati.

Transazioni

Teradata fornisce il livello di isolamento delle transazioni Read Uncommitted (che consente letture dirty) o Serializable quando viene eseguito in modalità sessione (anziché in modalità di commit automatico). Nel migliore dei casi, Teradata ottiene un isolamento rigorosamente serializzabile utilizzando il blocco pessimistico su un hash di riga in tutte le colonne di righe in tutte le partizioni. Sono possibili deadlock. Il DDL forza sempre un confine di transazione. I job Teradata Fastload vengono eseguiti in modo indipendente, ma solo su tabelle vuote.

BigQuery supporta anche le transazioni. BigQuery contribuisce a garantire il controllo della concorrenza ottimistica (vince il primo commit) con l'isolamento degli snapshot, in cui una query legge gli ultimi dati di cui è stato eseguito il commit prima dell'avvio della query. Questo approccio garantisce lo stesso livello di coerenza per riga, per mutazione e tra le righe all'interno della stessa istruzione DML, evitando al contempo i deadlock. In caso di più istruzioni UPDATE sulla stessa tabella, BigQuery passa al controllo della concorrenza pessimistico e mette in coda più istruzioni UPDATE, riprovando automaticamente in caso di conflitti. Le istruzioni DML e i job di caricamento INSERT possono essere eseguiti contemporaneamente e in modo indipendente per aggiungere dati alle tabelle.

Esegui il rollback

Teradata supporta due modalità di rollback della sessione, la modalità sessione ANSI e la modalità sessione Teradata (SET SESSION CHARACTERISTICS e SET SESSION TRANSACTION), a seconda della modalità di rollback che preferisci. In caso di errore, potrebbe non essere eseguito il rollback della transazione.

BigQuery supporta l'istruzione ROLLBACK TRANSACTION. In BigQuery non esiste un'istruzione ABORT.

Limiti per i database

Controlla sempre la documentazione pubblica di BigQuery per conoscere le quote e i limiti più recenti. Molte quote per gli utenti con volumi elevati possono essere aumentate contattando il team di assistenza Cloud. La tabella seguente mostra un confronto dei limiti dei database Teradata e BigQuery.

Limite	Teradata	BigQuery
Tabelle per database	Senza restrizioni	Senza restrizioni
Colonne per tabella	2048	10.000
Dimensione massima della riga	1 MB	100 MB
Lunghezza nome colonna	128 caratteri Unicode	300 caratteri Unicode
Lunghezza della descrizione della tabella	128 caratteri Unicode	16.384 caratteri Unicode
Righe per tabella	Illimitato	Illimitato
Lunghezza massima della richiesta SQL	1 MB	1 MB (lunghezza massima della query GoogleSQL non risolta) 12 MB (lunghezza massima della query legacy e GoogleSQL risolta) Flusso di dati: 10 MB (limite di dimensioni della richiesta HTTP) 10.000 (numero massimo di righe per richiesta)
Dimensioni massime di richiesta e risposta	7 MB (richiesta), 16 MB (risposta)	10 MB (richiesta) e 10 GB (risposta) o praticamente illimitato se utilizzi l'impaginazione o l'API Cloud Storage.
Numero massimo di sessioni simultanee	120 per motore di analisi (PE)	1000 query contemporanee con più istruzioni (possono essere aumentate con una prenotazione di slot), 300 richieste API contemporanee per utente.
Numero massimo di caricamenti (rapidi) simultanei	30 (valore predefinito: 5)	Nessun limite di contemporaneità; i job vengono messi in coda. 100.000 job di caricamento per progetto al giorno.