Anleitung zur Übersetzung von Teradata SQL

In diesem Dokument werden die Gemeinsamkeiten und Unterschiede in der SQL-Syntax zwischen Teradata und BigQuery beschrieben, damit Sie die Migration planen können. Verwenden Sie die Batch-SQL-Übersetzung, um Ihre SQL-Skripts im Bulk zu migrieren, oder die interaktive SQL-Übersetzung, um Ad-hoc-Abfragen zu übersetzen.

Datentypen

In diesem Abschnitt werden die Entsprechungen zwischen den Datentypen in Teradata und BigQuery beschrieben.

Teradata	BigQuery	Hinweise
`INTEGER`	`INT64`
`SMALLINT`	`INT64`
`BYTEINT`	`INT64`
`BIGINT`	`INT64`
`DECIMAL`	`NUMERIC, DECIMAL` `BIGNUMERIC, BIGDECIMAL`	Verwenden Sie `NUMERIC` (Alias-`DECIMAL`) von BigQuery, wenn die Skala (Ziffern nach dem Dezimalzeichen) <= 9 ist. Verwenden Sie `BIGNUMERIC` (Alias `BIGDECIMAL`) von BigQuery, wenn die Skalierung > 9 ist. Verwenden Sie die parametrisierten Dezimaldatentypen von BigQuery, wenn Sie benutzerdefinierte Ziffern- oder Skalierungsgrenzen erzwingen (Einschränkungen) müssen. Mit Teradata können Sie Werte mit höherer Genauigkeit durch Runden des gespeicherten Werts einfügen. Für Berechnungen behält Teradata jedoch die hohe Genauigkeit bei. Dies kann im Vergleich zum ANSI-Standard zu unerwartetem Rundungsverhalten führen.
`FLOAT`	`FLOAT64`
`NUMERIC`	`NUMERIC, DECIMAL` `BIGNUMERIC, BIGDECIMAL`	Verwenden Sie `NUMERIC` (Alias-`DECIMAL`) von BigQuery, wenn die Skala (Ziffern nach dem Dezimalzeichen) <= 9 ist. Verwenden Sie `BIGNUMERIC` (Alias `BIGDECIMAL`) von BigQuery, wenn die Skalierung > 9 ist. Verwenden Sie die parametrisierten Dezimaldatentypen von BigQuery, wenn Sie benutzerdefinierte Ziffern- oder Skalierungsgrenzen erzwingen (Einschränkungen) müssen. Mit Teradata können Sie Werte mit höherer Genauigkeit durch Runden des gespeicherten Werts einfügen. Für Berechnungen behält Teradata jedoch die hohe Genauigkeit bei. Dies kann im Vergleich zum ANSI-Standard zu unerwartetem Rundungsverhalten führen.
`NUMBER`	`NUMERIC, DECIMAL` `BIGNUMERIC, BIGDECIMAL`	Verwenden Sie `NUMERIC` (Alias-`DECIMAL`) von BigQuery, wenn die Skala (Ziffern nach dem Dezimalzeichen) <= 9 ist. Verwenden Sie `BIGNUMERIC` (Alias `BIGDECIMAL`) von BigQuery, wenn die Skalierung > 9 ist. Verwenden Sie die parametrisierten Dezimaldatentypen von BigQuery, wenn Sie benutzerdefinierte Ziffern- oder Skalierungsgrenzen erzwingen (Einschränkungen) müssen. Mit Teradata können Sie Werte mit höherer Genauigkeit durch Runden des gespeicherten Werts einfügen. Für Berechnungen behält Teradata jedoch die hohe Genauigkeit bei. Dies kann im Vergleich zum ANSI-Standard zu unerwartetem Rundungsverhalten führen.
`REAL`	`FLOAT64`
`CHAR/CHARACTER`	`STRING`	Verwenden Sie den parametrisierten `STRING`-Datentyp von BigQuery, wenn Sie eine maximale Zeichenlänge erzwingen müssen.
`VARCHAR`	`STRING`	Verwenden Sie den parametrisierten `STRING`-Datentyp von BigQuery, wenn Sie eine maximale Zeichenlänge erzwingen müssen.
`CLOB`	`STRING`
`JSON`	`JSON`
`BLOB`	`BYTES`
`BYTE`	`BYTES`
`VARBYTE`	`BYTES`
`DATE`	`DATE`	BigQuery unterstützt keine benutzerdefinierte Formatierung, die Teradata mit DataForm in SDF unterstützt.
`TIME`	`TIME`
`TIME WITH TIME ZONE`	`TIME`	Teradata speichert den Datentyp `TIME` in UTC und ermöglicht die Übergabe eines Offsets von UTC mit der Syntax `WITH TIME ZONE`. Der Datentyp `TIME` in BigQuery stellt eine Zeit dar, die unabhängig von einem Datum oder einer Zeitzone ist.
`TIMESTAMP`	`TIMESTAMP`	Der Datentyp `TIMESTAMP` ist sowohl in Teradata als auch in BigQuery auf Mikrosekunden genau. Teradata unterstützt Schaltsekunden, BigQuery hingegen nicht. Sowohl in Teradata als auch in BigQuery ist dieser Datentyp normalerweise mit einer UTC-Zeitzone verknüpft. Weitere Informationen
`TIMESTAMP WITH TIME ZONE`	`TIMESTAMP`	Für Teradata `TIMESTAMP` kann systemweit, pro Nutzer oder pro Spalte (mit `WITH TIME ZONE`) eine andere Zeitzone festgelegt werden. Für den BigQuery-`TIMESTAMP`-Typ wird UTC angenommen, wenn Sie keine Zeitzone angeben. Achten Sie darauf, dass Sie entweder die Zeitzoneninformationen korrekt exportieren (ohne den `DATE`- und `TIME`-Wert ohne Zeitzoneninformationen zu verketten), damit BigQuery sie beim Import konvertieren kann. Sie können die Zeitzoneninformationen auch vor dem Export in UTC konvertieren. BigQuery verfügt über `DATETIME` für eine Abstraktion zwischen amtlicher Zeit, die bei der Ausgabe keine Zeitzone anzeigt, und `TIMESTAMP`, einem genauen Zeitpunkt, an dem immer die UTC-Zeitzone angezeigt wird.
`ARRAY`	`ARRAY`
`MULTI-DIMENSIONAL ARRAY`	`ARRAY`	Verwenden Sie in BigQuery ein Array von Struct-Werten, in dem jeder Struct-Wert ein Feld vom Typ `ARRAY` enthält. Weitere Informationen finden Sie in der BigQuery-Dokumentation.
`INTERVAL HOUR`	`INT64`
`INTERVAL MINUTE`	`INT64`
`INTERVAL SECOND`	`INT64`
`INTERVAL DAY`	`INT64`
`INTERVAL MONTH`	`INT64`
`INTERVAL YEAR`	`INT64`
`PERIOD(DATE)`	`DATE`, `DATE`	`PERIOD(DATE)` sollte in zwei `DATE`-Spalten konvertiert werden, die das Startdatum und Enddatum enthalten, damit sie mit Fensterfunktionen verwendet werden können.
`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`

Weitere Informationen zur Typumwandlung finden Sie im nächsten Abschnitt.

Teradata-Formatierung

Teradata SQL verwendet eine Reihe von Standardformaten für die Anzeige von Ausdrücken und Spaltendaten sowie für die Konvertierung zwischen Datentypen. Beispiel: Ein PERIOD(DATE)-Datentyp im INTEGERDATE-Modus ist standardmäßig als YY/MM/DD formatiert. Wir empfehlen Ihnen, nach Möglichkeit den ANSIDATE-Modus zu verwenden, um die ANSI-SQL-Konformität zu gewährleisten, und diese Gelegenheit zu nutzen, um ältere Formate zu bereinigen.

Teradata ermöglicht die automatische Anwendung benutzerdefinierter Formate mit der FORMAT-Klausel, ohne den zugrunde liegenden Speicher zu ändern, entweder als Datentypattribut, wenn Sie eine Tabelle mit DDL erstellen, oder in einem abgeleiteten Ausdruck. Zum Beispiel rundet eine FORMAT-Spezifikation 9.99 einen beliebigen FLOAT-Wert auf zwei Ziffern. In BigQuery muss diese Funktion mithilfe der Funktion ROUND() konvertiert werden.

Diese Funktion erfordert die Bearbeitung komplizierter Grenzfälle. Wenn beispielsweise die FORMAT-Klausel auf eine NUMERIC-Spalte angewendet wird, müssen Sie spezielle Rundungs- und Formatierungsregeln berücksichtigen. Mit einer FORMAT-Klausel kann ein INTEGER-Epochenwert implizit in ein DATE-Format umgewandelt werden. Oder eine FORMAT-Spezifikation X(6) für eine VARCHAR-Spalte kürzt den Spaltenwert und muss daher in eine SUBSTR()-Funktion konvertiert werden. Dieses Verhalten ist nicht ANSI SQL-konform. Daher empfehlen wir, Spaltenformate nicht zu BigQuery zu migrieren.

Wenn Spaltenformate unbedingt erforderlich sind, verwenden Sie Ansichten oder benutzerdefinierte Funktionen (UDFs).

Informationen zu den Standardformaten, die Teradata SQL für jeden Datentyp verwendet, finden Sie in der Dokumentation zur Teradata-Standardformatierung.

Formatierung von Zeitstempel und Datumstyp

Die folgende Tabelle fasst die Unterschiede bei Elementen der Zeitstempel- und Datumsformatierung zwischen Teradata SQL und GoogleSQL zusammen.

Teradata-Format	Teradata-Beschreibung	BigQuery
`CURRENT_TIMESTAMP CURRENT_TIME`	`TIME`- und `TIMESTAMP`-Informationen in Teradata können unterschiedliche Zeitzoneninformationen haben, die mit `WITH TIME ZONE` definiert werden.	Verwenden Sie nach Möglichkeit `CURRENT_TIMESTAMP()`, formatiert im ISO-Format. Das Ausgabeformat zeigt jedoch immer die UTC-Zeitzone an. (Intern hat BigQuery keine Zeitzone.) Beachten Sie die folgenden Details zu den Unterschieden im ISO-Format. `DATETIME` wird basierend auf den Ausgabekanalkonventionen formatiert. Im BigQuery-Befehlszeilentool und in der BigQuery Console wird es mit einem `T`-Trennzeichen gemäß RFC 3339 formatiert. In Python und Java JDBC wird jedoch ein Leerzeichen als Trennzeichen verwendet. Wenn Sie ein explizites Format nutzen möchten, verwenden Sie `FORMAT_DATETIME()`, wodurch eine explizite Umwandlung eines Strings erfolgt. Der folgende Ausdruck gibt beispielsweise immer ein Leerzeichen als Trennzeichen zurück: `CAST(CURRENT_DATETIME() AS STRING)` Teradata unterstützt ein `DEFAULT`-Keyword in `TIME`-Spalten, um die aktuelle Zeit festzulegen (Zeitstempel). Dies wird in BigQuery nicht verwendet.
`CURRENT_DATE`	Datumsangaben werden in Teradata mithilfe der folgenden Formel als `INT64`-Werte gespeichert: `(YEAR - 1900) * 10000 + (MONTH * 100) + DAY` Datumsangaben können als Ganzzahlen formatiert werden.	BigQuery hat ein separates `DATE`-Format, das immer ein Datum im ISO 8601-Format zurückgibt. `DATE_FROM_UNIX_DATE` kann nicht verwendet werden, da es auf 1970 basiert. Teradata unterstützt ein `DEFAULT`-Keyword in `DATE`-Spalten, um das aktuelle Datum festzulegen. Dies wird in BigQuery nicht verwendet.
`CURRENT_DATE-3`	Datumswerte werden als Ganzzahlen dargestellt. Teradata unterstützt arithmetische Operatoren für Datumstypen.	Verwenden Sie für Datumstypen `DATE_ADD()` oder `DATE_SUB()`. BigQuery verwendet arithmetische Operatoren für die Datentypen `INT64`, `NUMERIC` und `FLOAT64`.
`SYS_CALENDAR.CALENDAR`	Teradata bietet eine Ansicht für Kalendervorgänge, die über Ganzzahlvorgänge hinausgehen.	Wird in BigQuery nicht verwendet.
`SET SESSION DATEFORM=ANSIDATE`	Setzen Sie das Sitzungs- oder Systemdatumsformat auf ANSI (ISO 8601).	BigQuery verwendet immer ISO 8601. Gewährleisten Sie daher, dass Sie Teradata-Datums- und Zeitangaben konvertieren.

Abfragesyntax

In diesem Abschnitt werden Unterschiede in der Abfragesyntax zwischen Teradata und BigQuery behandelt.

`SELECT`-Anweisung

Die meisten Teradata-SELECT-Anweisungen sind mit BigQuery kompatibel. Die folgende Tabelle enthält eine Liste der geringfügigen Unterschiede.

Teradata		BigQuery
`SEL`		Zu `SELECT` konvertieren. BigQuery verwendet nicht die Abkürzung `SEL`.
`SELECT (subquery) AS flag, CASE WHEN flag = 1 THEN ...`		In BigQuery können Spalten nicht auf die Ausgabe anderer Spalten verweisen, die in derselben Auswahlliste definiert sind. Ziehen Sie daher in Betracht, eine Unterabfrage in eine `WITH`-Klausel zu verschieben. `WITH flags AS ( subquery ), SELECT CASE WHEN flags.flag = 1 THEN ...`
`SELECT * FROM table WHERE A LIKE ANY ('string1', 'string2')`		BigQuery verwendet nicht das logische Prädikat `ANY`. Dieselbe Funktionalität kann mit mehreren `OR`-Operatoren erreicht werden: `SELECT * FROM table WHERE col LIKE 'string1' OR col LIKE 'string2'` In diesem Fall unterscheidet sich der Stringvergleich ebenfalls. Siehe Vergleichsoperatoren.
`SELECT TOP 10 * FROM table`		BigQuery verwendet `LIMIT` am Ende einer Abfrage anstelle von `TOP n` nach dem Keyword `SELECT`.

Vergleichsoperator

Die folgende Tabelle zeigt Teradata-Vergleichsoperatoren, die für Teradata spezifisch sind und in die in BigQuery verwendeten ANSI SQL:2011-kompatiblen Operatoren konvertiert werden müssen.

Informationen zu Operatoren in BigQuery finden Sie im Abschnitt Operatoren der BigQuery-Dokumentation.

Teradata	BigQuery	Hinweise
`exp EQ exp2` `exp IN (exp2, exp3)`	`exp = exp2` `exp IN (exp2, exp3)` Wenn Sie die Nicht-ANSI-Semantik für `NOT CASESPECIFIC` beibehalten möchten, verwenden Sie `RTRIM(UPPER(exp)) = RTRIM(UPPER(exp2))`	Wenn Strings auf Gleichheit verglichen werden, ignoriert Teradata möglicherweise nachgestellte Leerzeichen, während BigQuery sie als Teil des Strings betrachtet. Beispiel: `'xyz'=' xyz'` ist in Teradata `TRUE`, in BigQuery jedoch `FALSE`. Teradata bietet auch ein `NOT CASESPECIFIC`-Spaltenattribut, das Teradata anweist, die Groß- und Kleinschreibung beim Vergleich von zwei Strings zu ignorieren. BigQuery beachtet beim Vergleich von Strings immer Groß- und Kleinschreibung. Beispiel: `'xYz' = 'xyz'` ist in Teradata `TRUE`, in BigQuery jedoch `FALSE`.
`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` Bedingungen

BigQuery und Teradata unterstützen dieselben JOIN-, ON- und USING-Bedingungen. Die folgende Tabelle enthält eine Liste der geringfügigen Unterschiede.

Teradata	BigQuery	Hinweise
`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 unterstützt Ungleichheits-`JOIN`-Klauseln für alle internen Joins oder wenn mindestens eine Gleichheitsbedingung angegeben ist (=). Aber nicht nur eine Ungleichheitsbedingung (= und <) in einem `OUTER JOIN`. Solche Konstrukte werden manchmal verwendet, um Datums- oder Ganzzahlbereiche abzufragen. BigQuery verhindert, dass Nutzer versehentlich große Cross Joins erstellen.
`FROM A, B ON A.id = B.id`	`FROM A JOIN B ON A.id = B.id`	Die Verwendung eines Kommas zwischen Tabellen in Teradata entspricht einem `INNER JOIN`, in BigQuery einem `CROSS JOIN` (kartesisches Produkt). Da das Komma in BigQuery Legacy-SQL als `UNION` behandelt wird, sollten Sie den Vorgang explizit machen, um Verwechslungen zu vermeiden.
`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))`	Kein Unterschied bei Skalarfunktionen (konstante Funktionen).
`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 verhindert, dass Nutzer Unterabfragen, korrelierte Unterabfragen oder Aggregationen in Join-Prädikaten verwenden. Dadurch kann BigQuery Abfragen parallelisieren.

Typkonvertierung und -umwandlung

BigQuery hat weniger, aber breitere Datentypen als Teradata, wodurch BigQuery beim Umwandeln strenger sein muss.

Teradata	BigQuery	Hinweise
`exp EQ exp2` `exp IN (exp2, exp3)`	`exp = exp2` `exp IN (exp2, exp3)` Wenn Sie die Nicht-ANSI-Semantik für `NOT CASESPECIFIC` beibehalten möchten, verwenden Sie `RTRIM(UPPER(exp)) = RTRIM(UPPER(exp2))`	Wenn Strings auf Gleichheit verglichen werden, ignoriert Teradata möglicherweise nachgestellte Leerzeichen, während BigQuery sie als Teil des Strings betrachtet. Beispiel: `'xyz'=' xyz'` ist in Teradata `TRUE`, in BigQuery jedoch `FALSE`. Teradata bietet auch ein `NOT CASESPECIFIC`-Spaltenattribut, das Teradata anweist, die Groß- und Kleinschreibung beim Vergleich von zwei Strings zu ignorieren. BigQuery beachtet beim Vergleich von Strings immer Groß- und Kleinschreibung. Beispiel: `'xYz' = 'xyz'` ist in Teradata `TRUE`, in BigQuery jedoch `FALSE`.
`CAST(long_varchar_column AS CHAR(6))`	`LPAD(long_varchar_column, 6)`	Die Umwandlung einer Zeichenspalte in Teradata wird manchmal als nicht standardmäßige und nicht optimale Methode zum Erstellen eines aufgefüllten Teilstrings verwendet.
`CAST(92617 AS TIME) 92617 (FORMAT '99:99:99')`	`PARSE_TIME("%k%M%S", CAST(92617 AS STRING))`	Teradata führt viel mehr implizite Typkonvertierungen und Rundungen durch als BigQuery, das in der Regel strenger ist und ANSI-Standards durchführt. (In diesem Beispiel wird 09:26:17 zurückgegeben)
`CAST(48.5 (FORMAT 'zz') AS FLOAT)`	`CAST(SUBSTR(CAST(48.5 AS STRING), 0, 2) AS FLOAT64)`	Für Gleitkomma- und numerische Datentypen können spezielle Rundungsregeln erforderlich sein, wenn sie auf Formate wie Währungen angewendet werden. (In diesem Beispiel werden 48 zurückgegeben)

Siehe auch Vergleichsoperatoren und Spaltenformate. Sowohl Vergleiche als auch Spaltenformatierungen können sich wie Typumwandlungen verhalten.

Klausel `QUALIFY`, `ROWS`

Mit der QUALIFY-Klausel in Teradata können Sie Ergebnisse für Fensterfunktionen filtern. Alternativ kann für dieselbe Aufgabe eine ROWS-Wortgruppe verwendet werden. Diese funktionieren ähnlich wie eine HAVING-Bedingung für eine GROUP-Klausel und schränken die Ausgabe dessen ein, was in BigQuery als aggregierte Fensterfunktionen bezeichnet wird.

Teradata BigQuery

SELECT col1, col2 FROM table QUALIFY ROW_NUMBER() OVER (PARTITION BY col1 ORDER BY col2) = 1; TeradataQUALIFY Klausel mit einer Fensterfunktion wieROW_NUMBER() ,SUM() ,COUNT() und mitOVER PARTITION BY wird in BigQuery alsWHERE Klausel für eine Unterabfrage, die einen Analysewert enthält.

Verwendung von ROW_NUMBER():

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

Verwendung von ARRAY_AGG, das größere Partitionen unterstützt:

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 können sowohl RANGE als auch ROWS in der Window Frame-Klausel verwendet werden. Window-Klauseln können jedoch nur mit Fensterfunktionen wie AVG() und nicht mit Nummerierungsfunktionen wie ROW_NUMBER() verwendet werden.

Teradata	BigQuery
`SELECT col1, col2 FROM table QUALIFY ROW_NUMBER() OVER (PARTITION BY col1 ORDER BY col2) = 1;`	Teradata`QUALIFY` Klausel mit einer Fensterfunktion wie`ROW_NUMBER()` ,`SUM()` ,`COUNT()` und mit`OVER PARTITION BY` wird in BigQuery als`WHERE` Klausel für eine Unterabfrage, die einen Analysewert enthält. Verwendung von `ROW_NUMBER()`: `SELECT col1, col2 FROM ( SELECT col1, col2, ROW_NUMBER() OVER (PARTITION BY col1 ORDER BY col2) RN FROM table ) WHERE RN = 1;` Verwendung von `ARRAY_AGG`, das größere Partitionen unterstützt: `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 können sowohl `RANGE` als auch `ROWS` in der Window Frame-Klausel verwendet werden. Window-Klauseln können jedoch nur mit Fensterfunktionen wie `AVG()` und nicht mit Nummerierungsfunktionen wie `ROW_NUMBER()` verwendet werden.

Keyword `NORMALIZE`

Teradata stellt das Keyword NORMALIZE für SELECT-Klauseln zur Verfügung, um überschneidende Zeiträume oder Intervalle zu einem einzelnen Zeitraum oder Intervall zusammenzufassen, der alle Werte einzelner Zeiträume umfasst.

BigQuery unterstützt den Typ PERIOD nicht. Daher muss jede Spalte des Typs PERIOD in Teradata als zwei separate DATE- oder DATETIME-Felder in BigQuery eingefügt werden, die dem Beginn und dem Ende des Zeitraums entsprechen.

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;

Funktionen

In den folgenden Abschnitten werden Zuordnungen zwischen Teradata-Funktionen und BigQuery-Entsprechungen aufgeführt.

Aggregatfunktionen

In der folgenden Tabelle werden gängige Teradata-Aggregatfunktionen, statistische Aggregatfunktionen und ungefähre Aggregatfunktionen ihren BigQuery-Entsprechungen zugeordnet. BigQuery bietet die folgenden zusätzlichen Aggregatfunktionen:

Teradata	BigQuery
`AVG`	`AVG`
`BITAND`	`BIT_AND`
`BITNOT`	Bitweiser Not-Operator (`~`)
`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`	Benutzerdefinierte Funktion
`STDDEV_POP`	`STDDEV_POP`
`STDDEV_SAMP`	`STDDEV_SAMP, STDDEV`
`SUM`	`SUM`
`VAR_POP`	`VAR_POP`
`VAR_SAMP`	`VAR_SAMP, VARIANCE`

Analysefunktionen und Fensterfunktionen

In der folgenden Tabelle werden gängige Teradata-Analysefunktionen und aggregierte Analysefunktionen ihren BigQuery-Fensterfunktionsäquivalenten zugeordnet. BigQuery bietet die folgenden zusätzlichen Funktionen:

Teradata	BigQuery
`ARRAY_AGG`	`ARRAY_AGG`
`ARRAY_CONCAT, (\|\| operator)`	`ARRAY_CONCAT_AGG, (\|\| operator)`
`BITAND`	`BIT_AND`
`BITNOT`	Bitweiser Not-Operator (`~`)
`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`

Datums-/Zeitfunktionen

In der folgenden Tabelle werden gängige Teradata-Datums-/Zeitfunktionen ihren BigQuery-Entsprechungen zugeordnet. BigQuery bietet die folgenden zusätzlichen Datums-/Zeitfunktionen:

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` Hinweis: Diese Funktion unterstützt die Eingabeausdrücke `DATE` und `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`

Stringfunktionen

In der folgenden Tabelle werden Teradata-Stringfunktionen ihren BigQuery-Entsprechungen zugeordnet. BigQuery bietet die folgenden zusätzlichen Stringfunktionen:

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`	Benutzerdefinierte Funktion
`CSVLD`	Benutzerdefinierte Funktion
`FORMAT`	`FORMAT`
`INDEX`	`STRPOS(string, substring)`
`INITCAP`	`INITCAP`
`INSTR`	Benutzerdefinierte Funktion
`LEFT`	`SUBSTR(source_string, 1, length)`
`LENGTH`	`LENGTH`
`LOWER`	`LOWER`
`LPAD`	`LPAD`
`LTRIM`	`LTRIM`
`NGRAM`	Benutzerdefinierte Funktion
`NVP`	Benutzerdefinierte Funktion
`OREPLACE`	`REPLACE`
`OTRANSLATE`	Benutzerdefinierte Funktion
`POSITION`	`STRPOS(string, substring)`
`REGEXP_INSTR`	`STRPOS(source_string, REGEXP_EXTRACT(source_string, regexp_string))` Hinweis: Gibt das erste Vorkommen zurück.
`REGEXP_REPLACE`	`REGEXP_REPLACE`
`REGEXP_SIMILAR`	`IF(REGEXP_CONTAINS,1,0)`
`REGEXP_SUBSTR`	`REGEXP_EXTRACT, REGEXP_EXTRACT_ALL`
`REGEXP_SPLIT_TO_TABLE`	Benutzerdefinierte Funktion
`REVERSE`	`REVERSE`
`RIGHT`	`SUBSTR(source_string, -1, length)`
`RPAD`	`RPAD`
`RTRIM`	`RTRIM`
`STRTOK` Hinweis: Jedes Zeichen im Argument des Trennzeichenstrings wird als separates Trennzeichen betrachtet. Das Standardtrennzeichen ist ein Leerzeichen.	`SPLIT(instring, delimiter)[ORDINAL(tokennum)]` Hinweis: Das gesamte delimiter-Stringargument wird als einzelnes Trennzeichen verwendet. Das Standardtrennzeichen ist ein Komma.
`STRTOK_SPLIT_TO_TABLE`	Benutzerdefinierte Funktion
`SUBSTRING`, `SUBSTR`	`SUBSTR`
`TRIM`	`TRIM`
`UPPER`	`UPPER`

Mathematische Funktionen:

In der folgenden Tabelle werden die mathematischen Funktionen von Teradata ihren BigQuery-Entsprechungen zugeordnet. BigQuery bietet die folgenden zusätzlichen mathematischen Funktionen:

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

DML-Syntax

In diesem Abschnitt werden Unterschiede in der Syntax der Datenverwaltungssprache zwischen Teradata und BigQuery behandelt.

`INSERT`-Anweisung

Die meisten Teradata-INSERT-Anweisungen sind mit BigQuery kompatibel. Die folgende Tabelle enthält Ausnahmen.

DML-Skripts in BigQuery haben eine etwas andere Konsistenzsemantik als die entsprechenden Anweisungen in Teradata. Eine Übersicht über die Snapshot-Isolation sowie die Sitzungs- und Transaktionsbehandlung finden Sie im Abschnitt CREATE INDEX an anderer Stelle in diesem Dokument.

Teradata BigQuery

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

Teradata bietet das Keyword DEFAULT für Spalten, die keine Nullwerte zulassen.

Hinweis: In BigQuery funktioniert das Weglassen von Spaltennamen in der Anweisung INSERT nur, wenn Werte für alle Spalten in der Zieltabelle auf der Grundlage ihrer ordinalen Positionen in aufsteigender Reihenfolge enthalten sind.

Teradata	BigQuery
`INSERT INTO table VALUES (...);`	`INSERT INTO table (...) VALUES (...);` Teradata bietet das Keyword `DEFAULT` für Spalten, die keine Nullwerte zulassen. Hinweis: In BigQuery funktioniert das Weglassen von Spaltennamen in der Anweisung `INSERT` nur, wenn Werte für alle Spalten in der Zieltabelle auf der Grundlage ihrer ordinalen Positionen in aufsteigender Reihenfolge enthalten sind.
`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 verwendet das Konzept der Anfrage mit mehreren Anweisungen, die mehrere `INSERT`-Anweisungen gleichzeitig sendet. In BigQuery wird dies aufgrund der impliziten Transaktionsgrenze zwischen Anweisungen nicht empfohlen. Verwenden Sie stattdessen `INSERT` mit mehreren Werten. BigQuery lässt gleichzeitige `INSERT`-Anweisungen zu, kann jedoch eine Warteschlange `UPDATE` enthalten. Ziehen Sie zur Verbesserung der Leistung die folgenden Ansätze in Betracht: Kombinieren Sie mehrere Zeilen in einer einzigen `INSERT`-Anweisung anstelle einer Zeile pro `INSERT`-Vorgang. Kombinieren Sie mehrere DML-Anweisungen (einschließlich `INSERT`) mit einer `MERGE`-Anweisung. Verwenden Sie `CREATE TABLE ... AS SELECT` zum Erstellen und Ausfüllen neuer Tabellen anstelle von `UPDATE` oder `DELETE`, insbesondere beim Abfragen von partitionierten Feldern oder Rollback oder Wiederherstellung.


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 verwendet das Konzept der Anfrage mit mehreren Anweisungen, die mehrere INSERT-Anweisungen gleichzeitig sendet. In BigQuery wird dies aufgrund der impliziten Transaktionsgrenze zwischen Anweisungen nicht empfohlen. Verwenden Sie stattdessen INSERT mit mehreren Werten.

BigQuery lässt gleichzeitige INSERT-Anweisungen zu, kann jedoch eine Warteschlange UPDATE enthalten. Ziehen Sie zur Verbesserung der Leistung die folgenden Ansätze in Betracht:

Kombinieren Sie mehrere Zeilen in einer einzigen INSERT-Anweisung anstelle einer Zeile pro INSERT-Vorgang.
Kombinieren Sie mehrere DML-Anweisungen (einschließlich INSERT) mit einer MERGE-Anweisung.
Verwenden Sie CREATE TABLE ... AS SELECT zum Erstellen und Ausfüllen neuer Tabellen anstelle von UPDATE oder DELETE, insbesondere beim Abfragen von partitionierten Feldern oder Rollback oder Wiederherstellung.

`UPDATE`-Anweisung

Die meisten Teradata UPDATE-Anweisungen sind bis auf die folgenden Elemente mit BigQuery kompatibel:

Wenn Sie eine FROM-Klausel verwenden, wird die Reihenfolge der FROM- und SET-Klauseln in Teradata und BigQuery umgekehrt.
In GoogleSQL muss jede UPDATE-Anweisung das Keyword WHERE, gefolgt von einer Bedingung, enthalten. Zum Aktualisieren aller Zeilen in der Tabelle verwenden Sie WHERE true.

Als Best Practice sollten Sie mehrere DML-Mutationen statt einzelner UPDATE- und INSERT-Anweisungen gruppieren. DML-Skripts in BigQuery haben eine etwas andere Konsistenzsemantik als entsprechende Anweisungen in Teradata. Eine Übersicht über die Snapshot-Isolation sowie die Sitzungs- und Transaktionsbehandlung finden Sie im Abschnitt CREATE INDEX an anderer Stelle in diesem Dokument.

Die folgende Tabelle zeigt Teradata-UPDATE-Anweisungen und BigQuery-Anweisungen, die dieselben Aufgaben ausführen.

Weitere Informationen zu UPDATE in BigQuery finden Sie in den BigQuery-UPDATE-Beispielen in der DML-Dokumentation.

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`- und `TRUNCATE`-Anweisungen

Sowohl mit der DELETE- als auch mit der TRUNCATE-Anweisung können Zeilen aus einer Tabelle entfernt werden, ohne dass sich dies auf das Tabellenschema oder die Indexe auswirkt. TRUNCATE wird weder in Teradata noch in BigQuery verwendet. Sie können jedoch DELETE-Anweisungen verwenden, um den gleichen Effekt zu erzielen.

In BigQuery muss die DELETE-Anweisung eine WHERE-Klausel enthalten. Verwenden Sie WHERE true, um alle Zeilen in der Tabelle (gekürzt) zu löschen. Um Vorgänge für sehr große Tabellen schneller zu kürzen, empfehlen wir die Verwendung der Anweisung CREATE OR REPLACE TABLE ... AS SELECT, wobei LIMIT 0 für dieselbe Tabelle verwendet wird, um sich selbst zu ersetzen. Achten Sie jedoch darauf, bei der Verwendung manuell Partitionierungs- und Clustering-Informationen hinzuzufügen.

Teradata entfernt gelöschte Zeilen später. Das bedeutet, dass DELETE-Vorgänge anfangs schneller als in BigQuery sind, später aber Ressourcen benötigen, insbesondere umfangreiche DELETE-Vorgänge, die sich auf den Großteil einer Tabelle auswirken. Um einen ähnlichen Ansatz in BigQuery zu verwenden, empfehlen wir, die Anzahl der DELETE-Vorgänge zu reduzieren, z. B. indem die Zeilen, die nicht gelöscht werden sollen, in eine neue Tabelle kopiert werden. Alternativ können Sie ganze Partitionen entfernen. Beide Optionen sind auf schnellere Vorgänge ausgelegt als atomare DML-Mutationen.

Weitere Informationen zu DELETE in BigQuery finden Sie in den DELETE-Beispielen in der DML-Dokumentation.

Teradata	BigQuery
`BEGIN TRANSACTION; LOCKING TABLE table_A FOR EXCLUSIVE; DELETE FROM table_A; INSERT INTO table_A SELECT * FROM table_B; END TRANSACTION;`	Das Ersetzen des Inhalts einer Tabelle durch die Abfrageausgabe entspricht einer Transaktion. Sie können dazu entweder einen Abfragevorgang oder einen Kopiervorgang verwenden. Abfragevorgang verwenden: `bq query --replace --destination_table table_A 'SELECT * FROM table_B';` Kopiervorgang verwenden: `bq cp -f table_A table_B`
`DELETE database.table ALL;`	`DELETE FROM table WHERE TRUE;` Oder für sehr große Tabellen: `CREATE OR REPLACE table AS SELECT * FROM table LIMIT 0;`

`MERGE`-Anweisung

Die MERGE-Anweisung kann die Vorgänge INSERT, UPDATE und DELETE in einer einzigen "upsert" -Anweisung kombinieren und die Vorgänge in kleinstmöglichen Schritten ausführen. Der MERGE-Vorgang muss mit maximal einer Quellzeile für jede Zielzeile übereinstimmen. BigQuery und Teradata folgen beide der ANSI-Syntax.

Der MERGE-Vorgang von Teradata ist auf den Abgleich von Primärschlüsseln innerhalb eines Zugriffsmodulprozessors (AMP) beschränkt. Im Gegensatz dazu gibt es in BigQuery keine Größen- oder Spaltenbeschränkung für MERGE-Vorgänge. Daher ist die Verwendung von MERGE eine nützliche Optimierung. Wenn es sich bei MERGE jedoch hauptsächlich um einen großen Löschvorgang handelt, lesen Sie die Optimierungen für DELETE an anderer Stelle in diesem Dokument.

DML-Skripts in BigQuery haben eine etwas andere Konsistenzsemantik als entsprechende Anweisungen in Teradata. Beispielsweise können die SET-Tabellen von Teradata im Sitzungsmodus während eines MERGE-Vorgangs Duplikate ignorieren. Eine Übersicht über die Verarbeitung von MULTISET- und SET-Tabellen, die Snapshot-Isolation sowie die Sitzungs- und Transaktionsbehandlung finden Sie im Abschnitt CREATE INDEX an anderer Stelle in diesem Dokument.

Von "ROWS" betroffene Variablen

In Teradata ist die ACTIVITY_COUNT-Variable eine ANSI-SQL-Erweiterung von Teradata, die mit der Anzahl der von einer DML-Anweisung betroffenen Zeilen gefüllt wird.

Die Systemvariable @@row_count in der Skriptfunktion hat eine ähnliche Funktionalität. In BigQuery ist es üblicher, den Rückgabewert numDmlAffectedRows in den Audit-Logs oder in den Ansichten INFORMATION_SCHEMA zu prüfen.

DDL-Syntax

In diesem Abschnitt werden Unterschiede in der Syntax der Datendefinitionssprache zwischen Teradata und BigQuery behandelt.

`CREATE TABLE`-Anweisung

Die meisten Teradata-CREATE TABLE-Anweisungen sind mit BigQuery kompatibel, mit Ausnahme der folgenden Syntaxelemente, die in BigQuery nicht verwendet werden:

MULTISET. Weitere Informationen finden Sie im Abschnitt CREATE INDEX.
VOLATILE. Weitere Informationen finden Sie im Abschnitt Temporäre Tabellen.
[NO] FALLBACK. Weitere Informationen finden Sie im Abschnitt Rollback.
[NO] BEFORE JOURNAL, [NO] AFTER JOURNAL
CHECKSUM = DEFAULT | val
DEFAULT MERGEBLOCKRATIO
PRIMARY INDEX (col, ...). Weitere Informationen finden Sie im Abschnitt CREATE INDEX.
UNIQUE PRIMARY INDEX. Weitere Informationen finden Sie im Abschnitt CREATE INDEX.
CONSTRAINT
DEFAULT
IDENTITY

Weitere Informationen zu CREATE TABLE in BigQuery finden Sie in den BigQuery CREATE-Beispielen in der DML-Dokumentation.

Optionen und Attribute für Spalten

Die folgenden Spaltenspezifikationen für die Anweisung CREATE TABLE werden in BigQuery nicht verwendet:

FORMAT 'format'. Weitere Informationen finden Sie im Abschnitt Teradata-Formatierung.
CHARACTER SET name. BigQuery verwendet immer die UTF-8-Codierung.
[NOT] CASESPECIFIC
COMPRESS val | (val, ...)

Teradata erweitert den ANSI-Standard um eine Spaltenoption TITLE. Diese Funktion kann in BigQuery auf ähnliche Weise mithilfe der Spaltenbeschreibung implementiert werden, wie in der folgenden Tabelle dargestellt. Diese Option ist für Ansichten nicht verfügbar.

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

Temporäre Tabellen

Teradata unterstützt flüchtige Tabellen, die häufig zum Speichern von Zwischenergebnissen in Skripts verwendet werden. Es gibt mehrere Möglichkeiten, flüchtige Tabellen in BigQuery zu erstellen:

CREATE TEMPORARY TABLE kann in Skripts verwendet werden und ist während der Laufzeit des Skripts gültig. Wenn die Tabelle über ein Skript hinaus vorhanden sein muss, können Sie die anderen Optionen in dieser Liste verwenden.
Dataset-TTL: Erstellen Sie ein Dataset mit einer kurzen Lebensdauer (z. B. 1 Stunde), damit alle im Dataset erstellten Tabellen praktisch temporär sind, da sie nicht länger als die Lebensdauer des Datasets beibehalten werden. Sie können allen Tabellennamen in diesem Dataset temp voranstellen, um deutlich zu machen, dass die Tabellen temporär sind.
Tabellen-TTL: Erstellen Sie eine Tabelle mit einer tabellenspezifischen Kurzlebigkeitsdauer mithilfe von DDL-Anweisungen wie der folgenden:
```
CREATE TABLE temp.name (col1, col2, ...)
OPTIONS(expiration_timestamp=TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL 1 HOUR));
```
WITH-Klausel: Wenn eine temporäre Tabelle nur im selben Block benötigt wird, verwenden Sie ein temporäres Ergebnis mithilfe einer WITH-Anweisung oder -Unterabfrage. Dies ist die effizienteste Option.

Ein in Teradata-Skripts (BTEQ) häufig verwendetes Muster besteht darin, eine permanente Tabelle zu erstellen, einen Wert einzufügen, diesen wie eine temporäre Tabelle in laufenden Anweisungen zu verwenden und die Tabelle anschließend zu löschen oder zu kürzen. In diesem Fall wird die Tabelle als konstante Variable (Semaphore) verwendet. Dieser Ansatz ist in BigQuery nicht effizient. Wir empfehlen, stattdessen echte Variablen in der Skripterstellung oder CREATE OR REPLACE mit der AS SELECT-Abfragesyntax zu verwenden, um eine Tabelle zu erstellen, die bereits Werte enthält.

`CREATE VIEW`-Anweisung

Die folgende Tabelle zeigt Entsprechungen zwischen Teradata und BigQuery für die Anweisung CREATE VIEW. Die Klauseln für die Tabellensperre wie LOCKING ROW FOR ACCESS werden in BigQuery nicht benötigt.

Teradata	BigQuery	Hinweise
`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 ...`
Nicht unterstützt	`CREATE VIEW IF NOT EXISTS OPTIONS(view_option_list) AS SELECT ...`	Erstellt nur dann eine neue Ansicht, wenn die Ansicht derzeit im angegebenen Dataset nicht vorhanden ist.

`CREATE [UNIQUE] INDEX`-Anweisung

Teradata erfordert Indexe für alle Tabellen und spezielle Problemumgehungen wie MULTISET-Tabellen und NoPI-Tabellen, um mit nicht eindeutigen oder nicht indexierten Daten zu arbeiten.

BigQuery erfordert keine Indexe. In diesem Abschnitt werden Ansätze in BigQuery beschrieben, die das Erstellen von Funktionen ermöglichen, ähnlich wie Indexe in Teradata verwendet werden, wenn es eine echte Geschäftslogik gibt.

Indexierung aus Gründen der Leistung

Da es sich um eine spaltenorientierte Datenbank mit Abfrage- und Speicheroptimierung handelt, benötigt BigQuery keine expliziten Indexe. BigQuery bietet Funktionen wie Partitionierung und Clustering sowie verschachtelte Felder, die durch Optimierung der Datenspeicherung die Effizienz und Leistung von Abfragen erhöhen können.

Teradata unterstützt keine materialisierten Ansichten. Es bietet jedoch Join-Indexe mit der CREATE JOIN INDEX-Anweisung, die im Wesentlichen Daten materialisiert, die für ein Join benötigt werden. BigQuery benötigt keine materialisierten Indexe, um die Leistung zu beschleunigen, und auch keinen dedizierten Spool-Bereich für Joins.

Für andere Optimierungsfälle können materialisierte Ansichten verwendet werden.

Indexierung aus Konsistenzgründen (UNIQUE, PRIMARY INDEX)

In Teradata kann ein eindeutiger Index verwendet werden, um Zeilen mit nicht eindeutigen Schlüsseln in einer Tabelle zu verhindern. Wenn ein Prozess versucht, Daten mit einem Wert einzufügen oder zu aktualisieren, der bereits im Index enthalten ist, schlägt der Vorgang entweder mit einem Indexverstoß fehl (MULTISET-Tabellen) oder ignoriert ihn (SET-Tabellen).

Da BigQuery keine expliziten Indexe bereitstellt, kann stattdessen eine MERGE-Anweisung verwendet werden, um nur eindeutige Einträge aus einer Staging-Tabelle in eine Zieltabelle einzufügen, während doppelte Einträge verworfen werden. Es gibt jedoch keine Möglichkeit, zu verhindern, dass ein Nutzer mit Bearbeitungsberechtigungen einen doppelten Eintrag einfügt, da BigQuery während INSERT-Vorgängen niemals gesperrt wird. Zum Generieren eines Fehlers für doppelte Einträge in BigQuery können Sie eine MERGE-Anweisung aus einer Staging-Tabelle verwenden, wie im folgenden Beispiel gezeigt.

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

Häufiger ziehen es Nutzer vor, Duplikate unabhängig zu entfernen, um Fehler in nachgelagerten Systemen zu finden.
BigQuery unterstützt die Spalten DEFAULT und IDENTITY (Sequenzen) nicht.

Indexierung, um eine Sperre zu erreichen

Teradata stellt Ressourcen im Zugriffsmodulprozessor (AMP) bereit. Abfragen können All-AMP-, Single-AMP- oder Gruppen-AMP-Ressourcen verbrauchen. DDL-Anweisungen sind vollständig AMP-ähnlich und ähneln daher einer globalen DDL-Sperre. BigQuery hat keinen solchen Sperrmechanismus und kann gleichzeitig Abfragen und INSERT-Anweisungen bis zu Ihrem Kontingent ausführen. Nur gleichzeitige UPDATE-DML-Anweisungen haben bestimmte Auswirkungen auf die Gleichzeitigkeit: UPDATE-Vorgänge für dieselbe Partition werden in die Warteschlange gestellt, um die Snapshot-Isolation zu gewährleisten. Sie müssen also nicht sperren, um fiktive Lesevorgänge oder verlorene Aktualisierungen zu verhindern.

Aufgrund dieser Unterschiede werden die folgenden Teradata-Elemente in BigQuery nicht verwendet:

ON COMMIT DELETE ROWS;
ON COMMIT PRESERVE ROWS;

Prozedurale SQL-Anweisungen

In diesem Abschnitt wird beschrieben, wie Sie prozedurale SQL-Anweisungen, die in gespeicherten Verfahren, Funktionen und Triggern verwendet werden, von Teradata in BigQuery-Skripts, Verfahren oder benutzerdefinierte Funktionen (UDFs) konvertieren. All dies können Systemadministratoren in der Ansicht INFORMATION_SCHEMA prüfen.

`CREATE PROCEDURE`-Anweisung

Gespeicherte Verfahren werden im Rahmen der Skripterstellung von BigQuery unterstützt.

In BigQuery bezieht sich die Skripterstellung auf die Verwendung von Kontrollanweisungen, während Verfahren benannte Skripts sind (bei Bedarf mit Argumenten), die von anderen Skripts aufgerufen und bei Bedarf dauerhaft gespeichert werden können. Eine benutzerdefinierte Funktion (UDF) kann auch in JavaScript geschrieben werden.

Teradata	BigQuery
`CREATE PROCEDURE`	`CREATE PROCEDURE`, wenn ein Name erforderlich ist, verwenden Sie andernfalls inline mit `BEGIN` oder in einer einzigen Zeile mit `CREATE TEMP FUNCTION`.
`REPLACE PROCEDURE`	`CREATE OR REPLACE PROCEDURE`
`CALL`	`CALL`

In den folgenden Abschnitten wird beschrieben, wie vorhandene prozedurale Teradata-Anweisungen in BigQuery-Skript-Anweisungen mit ähnlicher Funktionalität konvertiert werden.

Variablendeklaration und -zuweisung

BigQuery-Variablen sind während der Lebensdauer des Skripts gültig.

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

Fehlerbedingungs-Handler

Teradata verwendet Handler für Statuscodes in Verfahren zur Fehlerkontrolle. In BigQuery ist die Fehlerbehandlung eine Kernfunktion des Hauptsteuerungsablaufs, ähnlich wie in anderen Sprachen mit TRY ... CATCH-Blöcken.

Teradata	BigQuery
`DECLARE EXIT HANDLER FOR SQLEXCEPTION`	`BEGIN ... EXCEPTION WHEN ERROR THEN`
`SIGNAL sqlstate`	`RAISE message`
`DECLARE CONTINUE HANDLER FOR SQLSTATE VALUE 23505;`	Ausnahme-Handler, die für bestimmte Fehlerbedingungen ausgelöst werden, werden von BigQuery nicht verwendet. Wir empfehlen die Verwendung von `ASSERT`-Anweisungen, bei denen Exit-Bedingungen für Vorabprüfungen oder Debugging verwendet werden, da dies ANSI SQL:2011-konform ist.

Die Variable SQLSTATE in Teradata ähnelt der Systemvariablen @@error in BigQuery. In BigQuery werden Fehler häufiger mit dem Audit-Logging oder der Ansicht INFORMATION_SCHEMA untersucht.

Cursor-Deklarationen und -Vorgänge

Da BigQuery keine Cursor oder Sitzungen unterstützt, werden die folgenden Anweisungen in BigQuery nicht verwendet:

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;

Dynamische SQL-Anweisungen

Die Skriptfunktion in BigQuery unterstützt dynamische SQL-Anweisungen, die in der folgenden Tabelle dargestellt sind.

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

Die folgenden dynamischen SQL-Anweisungen werden in BigQuery nicht verwendet:

PREPARE stmt_id FROM sql_str;

Anweisungen zum Kontrollfluss

Die Skriptfunktion in BigQuery unterstützt Ablaufsteuerungsanweisungen, wie sie in der folgenden Tabelle dargestellt sind.

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;`	Blockkonstruktionen im GOTO-Stil werden in BigQuery nicht verwendet. Wir empfehlen, sie als benutzerdefinierte Funktionen (UDFs) umzuschreiben oder `ASSERT`-Anweisungen zu verwenden, bei denen sie für die Fehlerbehandlung verwendet werden.
`REPEAT stmts UNTIL condition END REPEAT;`	`WHILE condition DO stmts END WHILE`
`LEAVE outer_proc_label;`	`LEAVE` wird nicht für GOTO-Blöcke verwendet. Es wird als Synonym für `BREAK` verwendet, um eine `WHILE`-Schleife zu verlassen.
`LEAVE label;`	`LEAVE` wird nicht für GOTO-Blöcke verwendet. Es wird als Synonym für `BREAK` verwendet, um eine `WHILE`-Schleife zu verlassen.
`WITH RECURSIVE temp_table AS ( ... );`	Rekursive Abfragen, die auch als rekursive allgemeine Tabellenausdrücke (common table expressions, CTE) bezeichent werden, werden in BigQuery nicht verwendet. Sie können mit Arrays von `UNION ALL` umschrieben werden.

Die folgenden Anweisungen zum Kontrollfluss werden in BigQuery nicht verwendet, da BigQuery keine Cursor oder Sitzungen verwendet:

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

Metadaten- und Transaktions-SQL-Anweisungen

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` Die gleiche Abfrage ist gültig, um Spalteninformationen für Ansichten abzurufen. Weitere Informationen finden Sie in der Spaltenansicht in BigQuery `INFORMATION_SCHEMA`.
`SELECT * FROM dbc.tables WHERE tablekind = 'T';` (Teradata-DBC-Ansicht)	`SELECT * EXCEPT(is_typed) FROM mydataset.INFORMATION_SCHEMA.TABLES;` Weitere Informationen finden Sie unter Einführung in BigQuery `INFORMATION_SCHEMA`.
`HELP STATISTICS table_name;`	`APPROX_COUNT_DISTINCT(col)`
`COLLECT STATS USING SAMPLE ON table_name column (...);`	Wird in BigQuery nicht verwendet.
`LOCKING TABLE table_name FOR EXCLUSIVE;`	BigQuery verwendet immer die Snapshot-Isolation. Weitere Informationen finden Sie an anderer Stelle in diesem Dokument unter Konsistenzgarantien.
`SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL ...`	BigQuery verwendet immer die Snapshot-Isolation. Weitere Informationen finden Sie an anderer Stelle in diesem Dokument unter Konsistenzgarantien.
`BEGIN TRANSACTION; SELECT ... END TRANSACTION;`	BigQuery verwendet immer die Snapshot-Isolation. Weitere Informationen finden Sie an anderer Stelle in diesem Dokument unter Konsistenzgarantien.
`EXPLAIN ...`	Wird in BigQuery nicht verwendet. Ähnliche Funktionen sind die Erläuterung des Abfrageplans in der BigQuery-Web-UI und die in den `INFORMATION_SCHEMA`-Ansichten sowie im Audit-Logging in Cloud Monitoring sichtbare Slot-Zuweisung.

Mehrfachanweisungen und mehrzeilige SQL-Anweisungen

Sowohl Teradata als auch BigQuery unterstützen Transaktionen (Sitzungen) und unterstützen daher durch Semikolons getrennte Anweisungen, die konsistent zusammen ausgeführt werden. Weitere Informationen finden Sie unter Transaktionen mit mehreren Anweisungen.

Fehlercodes und -meldungen

Teradata-Fehlercodes und BigQuery-Fehlercodes sind unterschiedlich. Bei der Bereitstellung einer REST API stützt sich BigQuery hauptsächlich auf HTTP-Statuscodes sowie detaillierte Fehlermeldungen.

Wenn Ihre Anwendungslogik derzeit die folgenden Fehler erkennt, versuchen Sie, die Fehlerquelle zu beheben, da BigQuery nicht die gleichen Fehlercodes zurückgibt.

SQLSTATE = '02000' — "Zeile nicht gefunden"
SQLSTATE = '21000' — "Kardinalitätsverstoß (Unique Index)"
SQLSTATE = '22000' — "Datenverstoß (Datentyp)"
SQLSTATE = '23000' — "Verstoß gegen die Beschränkung"

In BigQuery ist es üblicher, die INFORMATION_SCHEMA-Ansichten oder das Audit-Logging zur Aufschlüsselung von Fehlern zu verwenden.

Informationen zum Umgang mit Fehlern in der Skripterstellung finden Sie in den folgenden Abschnitten.

Konsistenzgarantien und Transaktionsisolation

Sowohl Teradata als auch BigQuery sind unteilbar, d. h. ACID-konform auf Mutationsebene über viele Zeilen hinweg. Zum Beispiel ist ein MERGE-Vorgang vollständig unteilbar, auch wenn mehrere eingefügte und aktualisierte Werte vorhanden sind.

Transaktionen

Teradata bietet beim Ausführen im Sitzungsmodus (nicht im automatischen Commit-Modus) entweder die Isolationsebene "Read Uncommitted" (Lesen ohne Commit – schmutzige Lesevorgänge möglich) oder serialisierbare Transaktionen. Im besten Fall erreicht Teradata eine strikt serialisierbare Isolation durch eine pessimistische Sperrung eines Zeilen-Hash in allen Spalten von Zeilen in allen Partitionen. Deadlocks sind möglich. DDL erzwingt immer eine Transaktionsgrenze. Teradata Fastload-Jobs werden unabhängig, aber nur für leere Tabellen ausgeführt.

BigQuery unterstützt auch Transaktionen. BigQuery sorgt mit der Snapshot-Isolation für eine optimistische Gleichzeitigkeitserkennung (der erste Commit erhält Vorrang), bei der eine Abfrage die letzten übergebenen Daten liest, bevor die Abfrage beginnt. Dieser Ansatz garantiert die gleiche Konsistenz auf Zeilen- und Mutationsbasis sowie zeilenübergreifend innerhalb derselben DML-Anweisung, vermeidet dabei jedoch Deadlocks. Bei mehreren UPDATE-Anweisungen für dieselbe Tabelle wechselt BigQuery zu pessimistischer Gleichzeitigkeitserkennung und stellt mehrfache UPDATE-Anweisungen in die Warteschlange. Bei Konflikten werden die Anweisungen automatisch wiederholt. INSERT-DML-Anweisungen und Ladejobs können gleichzeitig und unabhängig ausgeführt werden, um Daten an Tabellen anzuhängen.

Rollback

Teradata unterstützt je nach gewünschtem Rollback-Modus zwei Sitzungs-Rollback-Modi, den ANSI-Sitzungsmodus und den Teradata-Sitzungsmodus (SET SESSION CHARACTERISTICS und SET SESSION TRANSACTION). Bei Fehlern wird für die Transaktion möglicherweise kein Rollback durchgeführt.

BigQuery unterstützt die Anweisung ROLLBACK TRANSACTION. In BigQuery gibt es keine ABORT-Anweisung.

Datenbanklimits

Die aktuellen Kontingente und Limits finden Sie immer in der öffentlichen BigQuery-Dokumentation . Viele Kontingente für Nutzer mit hohem Datenvolumen können durch Kontaktaufnahme mit dem Cloud-Supportteam erhöht werden. Die folgende Tabelle zeigt einen Vergleich der Teradata- und BigQuery-Datenbanklimits.

Limit	Teradata	BigQuery
Tabellen pro Datenbank	Uneingeschränkt	Uneingeschränkt
Spalten pro Tabelle	2.048	10.000
Maximale Zeilengröße	1 MB	100 MB
Länge des Spalten- und Tabellennamens	128 Unicode-Zeichen	16.384 Unicode-Zeichen
Zeilen pro Tabelle	Unbegrenzt	Unbegrenzt
Maximale Länge von SQL-Anfragen	1 MB	1 MB (maximale Länge ungelöster GoogleSQL-Abfragen) 12 MB (maximale Länge der gelösten Legacy- und GoogleSQL-Abfragen) Streaming: . 10 MB (Größenbeschränkung für HTTP-Anfragen) 10.000 (maximale Zeilen pro Anfrage)
Maximale Anfrage- und Antwortgröße	7 MB (Anfrage), 16 MB (Antwort)	10 MB (Anfrage) und 10 GB (Antwort) oder praktisch unbegrenzt, wenn Sie den Seitenumbruch oder die Cloud Storage API verwenden.
Maximale Anzahl gleichzeitiger Sitzungen	120 pro Parsing-Engine (PE)	100 gleichzeitige Abfragen (kann mit einer Slot-Reservierung erhöht werden), 300 gleichzeitige API-Anfragen pro Nutzer
Maximale Anzahl gleichzeitiger (schneller) Ladevorgänge	30 (Standardeinstellung 5)	Keine Beschränkung der Gleichzeitigkeit; Jobs werden in die Warteschlange gestellt. 100.000 Ladejobs pro Projekt und Tag.

Anleitung zur Übersetzung von Teradata SQL

Datentypen

Teradata-Formatierung

Formatierung von Zeitstempel und Datumstyp

Abfragesyntax

SELECT-Anweisung

Vergleichsoperator

JOIN Bedingungen

Typkonvertierung und -umwandlung

Klausel QUALIFY, ROWS

Keyword NORMALIZE

Funktionen

Aggregatfunktionen

Analysefunktionen und Fensterfunktionen

Datums-/Zeitfunktionen

Stringfunktionen

Mathematische Funktionen:

DML-Syntax

INSERT-Anweisung

UPDATE-Anweisung

DELETE- und TRUNCATE-Anweisungen

MERGE-Anweisung

Von "ROWS" betroffene Variablen

DDL-Syntax

CREATE TABLE-Anweisung

Optionen und Attribute für Spalten

Temporäre Tabellen

CREATE VIEW-Anweisung

CREATE [UNIQUE] INDEX-Anweisung

Indexierung aus Gründen der Leistung

Indexierung aus Konsistenzgründen (UNIQUE, PRIMARY INDEX)

Indexierung, um eine Sperre zu erreichen

Prozedurale SQL-Anweisungen

CREATE PROCEDURE-Anweisung

Variablendeklaration und -zuweisung

Fehlerbedingungs-Handler

Cursor-Deklarationen und -Vorgänge

Dynamische SQL-Anweisungen

Anweisungen zum Kontrollfluss

Metadaten- und Transaktions-SQL-Anweisungen

Mehrfachanweisungen und mehrzeilige SQL-Anweisungen

Fehlercodes und -meldungen

Konsistenzgarantien und Transaktionsisolation

Transaktionen

Rollback

Datenbanklimits

`SELECT`-Anweisung

`JOIN` Bedingungen

Klausel `QUALIFY`, `ROWS`

Keyword `NORMALIZE`

`INSERT`-Anweisung

`UPDATE`-Anweisung

`DELETE`- und `TRUNCATE`-Anweisungen

`MERGE`-Anweisung

`CREATE TABLE`-Anweisung

`CREATE VIEW`-Anweisung

`CREATE [UNIQUE] INDEX`-Anweisung

`CREATE PROCEDURE`-Anweisung