Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

SQL-Übersetzungen mit YAML transformieren

Mit YAML-Konfigurationsdateien können Sie anpassen, wie BigQuery SQL-Code aus Ihrer Quelldatenbank während einer Migration übersetzt. Der BigQuery Migration Service unterstützt zwei Arten von YAML-Konfigurationsdateien: *.config.yaml-Übersetzungskonfigurationsdateien, die der Übersetzungs-Engine deterministische Regeln vorgeben, und *.ai_config.yaml-Gemini-basierte Konfigurationsdateien, die Gemini Regeln in natürlicher Sprache vorgeben.

So passen Sie eine SQL-Übersetzung mit YAML-Konfigurationsdateien an:

Konfigurationsdateien erstellen: Erstellen Sie deterministische *.config.yaml-Übersetzungskonfigurationsdateien, Gemini-basierte *.ai_config.yaml-Konfigurationsdateien oder beide Arten von Konfigurationsdateien, um strukturelle Regeln mit Gemini-Anpassungen zu kombinieren.
Dateien für einen Übersetzungsjob bereitstellen: Senden Sie die Konfigurationsdateien, wenn Sie eine einzelne Abfrage oder Batch-SQL-Dateien übersetzen.
Übersetzungsausgaben prüfen: Suchen Sie das übersetzte SQL und die Gemini-Vorschläge in der Antwort, wenn Sie eine einzelne Abfrage übersetzen, oder in Cloud Storage, wenn Sie Batch-SQL-Dateien übersetzen.

Arten von YAML-Konfigurationsdateien

In der folgenden Tabelle werden die beiden Arten von YAML-Konfigurationsdateien verglichen:

Funktion	Übersetzungskonfiguration (`*.config.yaml`)	Gemini-basierte Konfiguration (`*.ai_config.yaml`)
So werden Regeln angewendet	Regeln werden von der Übersetzungs-Engine als deterministische Regeln auf das geparste SQL angewendet. Daher erzeugen dieselbe Eingabe und Konfiguration immer dieselbe Ausgabe.	Regeln werden von Gemini als Anweisungen in natürlicher Sprache und Beispiele auf den SQL-Text angewendet. Die Ausgabe kann von Ausführung zu Ausführung variieren. Prüfen Sie daher immer die Vorschläge, bevor Sie sie verwenden.
Was kann transformiert werden?	Das Übersetzungsmodul kann alle Objekte oder Einstellungen transformieren, die es erkennt. Dazu gehören Datenbank-, Schema-, Tabellen-, Spalten- und Funktionsnamen und -typen, Tabelleneigenschaften wie Partitionierung, Clustering und Ablauf, Sitzungsstandardwerte, UDF-Signaturen, Optimierungen und Anweisungsausgaben wie der `GROUP BY`- und `SELECT *`-Stil.	Gemini kann jede SQL-Transformation ändern, die Sie in natürlicher Sprache beschreiben können. Dazu gehören Formatierungen und Kommentare, das Ersetzen von Mustern, das Umschreiben von Konstrukten, die von der Engine nicht wie gewünscht übersetzt werden, und das Generieren einer Erklärung der Übersetzung.
Voraussetzungen	Der Eingabe-SQL-Code muss im Quelldialekt geparst werden. Regeln können nicht auf Text in der Eingabe-SQL angewendet werden, den der Parser nicht erkennt, z. B. `${VAR}`-Platzhalter oder Vorlagensyntax. Verwenden Sie eine `SOURCE_SQL`-Regel in `*.ai_config.yaml`-Dateien oder Ihre eigene Vorverarbeitung, um solchen Text zuerst zu entfernen.	Sie müssen Gemini AI-Vorschläge für den Job aktivieren. Der Job muss an einem unterstützten Verarbeitungsstandort ausgeführt werden. Die Nutzung von Gemini ist bis zu einem bestimmten Limit kostenlos.
Wo das Ergebnis angezeigt wird	Das Ergebnis wird in der übersetzten SQL-Anweisung selbst angezeigt, z. B. in der Übersetzungsantwort oder im Ausgabeverzeichnis `sql/` in Cloud Storage.	Das Ergebnis wird als separate Gemini-Vorschläge in der Google Cloud Console, in separaten Vorschlagsfeldern oder Ausgabedateien in der Google Cloud CLI und auf dem MCP-Server oder in separaten`*_suggestion/`-Ausgabeverzeichnissen in Cloud Storage angezeigt. Weitere Informationen finden Sie unter Wo finde ich Übersetzungsausgaben?.
Dateiname	Die Dateiendung muss `.config.yaml` lauten, z. B. `rename-tables.config.yaml`.	Die Dateiendung muss `.ai_config.yaml` lauten, z. B. `style-rules.ai_config.yaml`.
Dateiname	Der Übersetzungsdienst ignoriert alle YAML-Dateien in der Eingabe, die nicht auf `.config.yaml` oder `.ai_config.yaml` enden, und meldet die ignorierte Datei im Übersetzungsprotokoll.
Referenz	Weitere Informationen finden Sie unter Richtlinien zum Erstellen einer YAML-Konfigurationsdatei und Beispiele für YAML-Konfigurationsdateien auf dieser Seite.	Weitere Informationen finden Sie auf dieser Seite unter Gemini-basierte YAML-Konfigurationsdatei erstellen.

Anwendung der beiden Regeltypen

Bei einem Übersetzungsjob werden Konfigurationsregeln in der folgenden Reihenfolge angewendet:

Gemini wendet SOURCE_SQL Regeln in *.ai_config.yaml Dateien auf die ursprüngliche SQL-Eingabe an, um umgeschriebene SQL-Quelldaten zu generieren.
Die Übersetzungs-Engine übersetzt das umgeschriebene Quell-SQL aus dem vorherigen Schritt oder das ursprüngliche Eingabe-SQL, wenn keine SOURCE_SQL-Regeln gelten, und wendet alle Regeln in *.config.yaml-Dateien an, um das übersetzte SQL zu erzeugen.
Gemini wendet TARGET_SQL Regeln in *.ai_config.yaml Dateien auf das übersetzte SQL aus dem vorherigen Schritt an, um umgeschriebenes Ziel-SQL zu erstellen. Wenn Ihre *.ai_config.yaml-Dateien TRANSLATION_EXPLANATION-Regeln enthalten, generiert Gemini auch eine Texterklärung des übersetzten SQL-Codes.

Wir empfehlen, *.config.yaml-Regeln für wiederholbare, strukturelle Änderungen wie das Umbenennen von Objekten, das Zuordnen von Typen und das Festlegen der Partitionierung zu verwenden. Wir empfehlen, *.ai_config.yaml-Regeln für Änderungen zu verwenden, die die Engine nicht ausdrücken kann, oder zum Bereinigen von Eingaben, die nicht geparst werden können. Sie können beide Arten von Konfigurationsdateien im selben Job verwenden.

Konfigurationsdateien für eine Übersetzung bereitstellen

Die Google Cloud Console, die gcloud CLI, die BigQuery Migration API und der MCP-Server des BigQuery Migration Service unterstützen die Verwendung mehrerer Konfigurationsdateien in einem einzigen Übersetzungsjob. Weitere Informationen finden Sie unter Mehrere YAML-Konfigurationen anwenden.

Wählen Sie eine der folgenden Optionen aus, um Konfigurationsdateien für einen Übersetzungsjob bereitzustellen:

Console

Wenn Sie Konfigurationsdateien beim Übersetzen einer einzelnen Abfrage verwenden möchten, geben Sie sie in den Übersetzungseinstellungen des interaktiven Übersetzers an:
- *.config.yaml: Geben Sie im Feld Speicherort der Übersetzungskonfiguration in den Übersetzungseinstellungen einen Cloud Storage-Pfad zur Konfigurationsdatei an.
- *.ai_config.yaml: Erstellen Sie Anpassungsregeln, die in __default.ai_config.yaml gespeichert werden, oder geben Sie einen Cloud Storage-Pfad an.
So verwenden Sie Konfigurationsdateien bei der Batchübersetzung von SQL-Dateien:
- *.config.yaml: Laden Sie die Konfigurationsdateien in das Cloud Storage-Eingabeverzeichnis hoch und geben Sie dann in den Übersetzungseinstellungen im Feld Details zum Dateispeicherort einen Pfad zum Verzeichnis an.
- *.ai_config.yaml: Laden Sie die Konfigurationsdateien in das Cloud Storage-Eingabeverzeichnis hoch und wählen Sie dann in den Übersetzungseinstellungen Optionale Einstellungen > Gemini AI-Vorschläge aus.

gcloud

Wenn Sie den Befehl gcloud alpha bq migration translate verwenden, geben Sie mit dem Flag --translation-config-files entweder *.config.yaml- oder *.ai_config.yaml-Dateien an.
Wenn Sie den Befehl gcloud alpha bq migration translate-batch verwenden, haben Sie folgende Möglichkeiten:
- *.config.yaml: Schließen Sie die Dateien im Eingabeverzeichnis ein, die Sie an --source-gcs-uris oder --source-local-dirs übergeben, oder übergeben Sie einzelne Dateien mit dem Flag --source-gcs-files oder --source-local-files.
- *.ai_config.yaml: Schließen Sie die Dateien im Eingabeverzeichnis ein, das Sie an --source-gcs-uris oder --source-local-dirs übergeben, oder übergeben Sie einzelne Dateien mit dem Flag --source-gcs-files oder --source-local-files und fügen Sie das Flag --enable-ai-suggestion hinzu.

API

In der BigQuery Migration API gehen Sie so vor, unabhängig davon, ob Sie eine einzelne Abfrage oder Batch-SQL-Dateien übersetzen:

*.config.yaml: Laden Sie die Dateien unter dem Eingabepfad in source_spec.base_uri hoch, übergeben Sie einen gcs_file_path-Eintrag in source_spec, wenn sich die Datei nicht unter base_uri befindet, oder übergeben Sie einen Inline-literal-Eintrag in source_spec.
*.ai_config.yaml: Stellen Sie die Dateien in source_spec unter base_uri bereit, als gcs_file_path-Eintrag, wenn sich die Datei nicht unter base_uri befindet, oder als Inline-literal-Eintrag. Fügen Sie "suggestion" in target_types ein, z. B. "target_types": ["sql", "suggestion"].

MCP

Im BigQuery Migration Service-MCP-Server:

So übersetzen Sie eine einzelne Abfrage (translate_query):
- *.config.yaml: Inline-translationConfigs-Einträge übergeben.
- *.ai_config.yaml: Inline-aiSuggestionConfigs-Einträge übergeben.
So übersetzen Sie Batch-SQL-Dateien (translate_batch_queries):
- *.config.yaml: Laden Sie die Dateien unter sourceBaseUri hoch oder listen Sie sie in configurationFilePaths auf, wenn sie sich nicht unter sourceBaseUri befinden.
- *.ai_config.yaml: Laden Sie die Dateien unter sourceBaseUri hoch oder listen Sie sie in configurationFilePaths auf, wenn sie sich nicht unter sourceBaseUri befinden, und setzen Sie enableAiSuggestions auf true.

Wo finde ich die Übersetzungsausgaben?

Je nach den von Ihnen bereitgestellten Konfigurationsdateien kann ein Übersetzungsjob die folgenden Ausgaben erzeugen:

Übersetztes SQL aus der Übersetzungs-Engine, nachdem alle Regeln in *.config.yaml-Dateien angewendet wurden.
Neu geschriebener Quell-SQL-Code von Gemini, nachdem SOURCE_SQL Regeln in *.ai_config.yaml Dateien angewendet wurden.
Neu geschriebenes Ziel-SQL von Gemini, nachdem TARGET_SQL Regeln in *.ai_config.yaml Dateien angewendet wurden.
Eine Übersetzungserklärung von Gemini, wenn Ihre *.ai_config.yaml-Dateien TRANSLATION_EXPLANATION-Regeln enthalten oder wenn Sie eine Erklärung anfordern.

Wo Sie diese Ausgaben finden, hängt davon ab, wie Sie die Übersetzung ausführen:

Informationen zum Suchen von Ausgaben, wenn Sie eine einzelne Abfrage in derGoogle Cloud Console oder der gcloud CLI übersetzen, finden Sie im Leitfaden zur interaktiven SQL-Übersetzung unter Übersetzungsausgabe untersuchen.
Informationen dazu, wie Sie Ausgaben finden, wenn Sie Batch-SQL-Dateien in Cloud Storage übersetzen oder in der Google Cloud -Konsole prüfen, finden Sie im Leitfaden zum Batch-SQL-Übersetzer unter Übersetzungsausgabe ansehen.
Informationen zum Suchen von Ausgaben bei Verwendung der BigQuery Migration API finden Sie im BigQuery Migration API-Leitfaden unter Ergebnisse abrufen. Fügen Sie für Übersetzungen mit einer einzelnen Abfrage die gewünschten Ausgabepfade (sql/<var>PATH</var>, source_sql_query_customization_suggestion/<var>PATH</var>, target_sql_query_customization_suggestion/<var>PATH</var> oder translation_explanation_suggestion/<var>PATH</var>) zu target_return_literals hinzu, um sie in translatedLiterals zu erhalten.
Informationen zum Suchen von Ausgaben bei Verwendung des MCP-Servers von BigQuery Migration Service finden Sie unter MCP-Server von BigQuery Migration Service verwenden. Die Tools translate_query und get_translation geben translatedQuery, sourceSqlSuggestion und targetSqlSuggestion zurück. Das Tool explain_translation gibt eine Erläuterung der Übersetzung zurück.

Anforderungen an die Übersetzungsdatei für `*.config.yaml`

Eine Übersetzungs-*.config.yaml-Datei muss die folgenden Anforderungen erfüllen, um mit dem BigQuery Migration Service kompatibel zu sein:

Wenn Sie *.config.yaml-Dateien im Cloud Storage-Eingabepfad für einen Batchübersetzungsjob hochladen, gelten Konfigurationsdateien, die sich an einer beliebigen Stelle im Eingabepfad befinden, für den gesamten Job. Sie müssen sich nicht auf der Stammebene befinden oder in jedes Unterverzeichnis kopiert werden. Informationen zum Erstellen von Buckets und zum Hochladen von Dateien in Cloud Storage erhalten Sie unter Buckets erstellen und Objekte aus einem Dateisystem hochladen.
Die Dateigröße für eine einzelne *.config.yaml-Datei darf 1 MB nicht überschreiten.
Die Gesamtgröße aller *.config.yaml-Dateien, die in einem einzelnen SQL-Übersetzungsjob verwendet werden, darf 4 MB nicht überschreiten.
Wenn Sie die regex-Syntax für den Namensabgleich verwenden, nutzen Sie RE2/J.
Alle Namen von Übersetzungskonfigurationsdateien müssen auf .config.yaml enden, z. B. change-case.config.yaml. config.yaml allein ist kein gültiger Name für die Konfigurationsdatei.

Richtlinien zum Erstellen einer YAML-Konfigurationsdatei

In diesem Abschnitt finden Sie einige allgemeine Richtlinien zum Erstellen einer YAML-Konfigurationsdatei:

Jede *.config.yaml-Datei muss einen type-Header auf oberster Ebene enthalten, der die Kategorie der Konfigurationsregeln in der Datei angibt:

object_rewriter: Schreibt relation-Attribute wie temporary, ephemeral, partitionLifetime, external, description, partition und clustering sowie attribute-Datentypen (type) um.
experimental_object_rewriter: Schreibt Ausgabedateinamen mit outputName in global, database, schema, relation, attribute, function, index, sequence, variable und projection um und konvertiert Datentypen global mit global.typeConvert. Weitere Informationen finden Sie unter Ausgabenamenszuordnung und Globale Typkonvertierung.
environment: Legt Standardeinstellungen auf Sitzungsebene unter session fest, z. B. defaultDatabase, schemaSearchPath und dateFormat.
metadata: Deklariert Signaturen für benutzerdefinierte Funktionen (UDFs) (udfs) und entfernt Präfixe, Suffixe oder reguläre Ausdrucksmuster aus Eingabenamen während der Metadatensuche (nameAlias).
statement_rewriter: Passt die Ausgabe von Anweisungen an, z. B. die Erweiterung von SELECT *, die Formatierung von GROUP BY und ORDER BY (select) sowie die Genauigkeit von Dezimalzahlen oder Strings (common).
input_formats: Gibt die Zeichencodierung der SQL-Eingabedateien an (formats).
optimizer: Aktiviert, deaktiviert oder konfiguriert optionale Abfrageoptimierungen (transformations).

Im folgenden Beispiel wird der Typ experimental_object_rewriter verwendet, um alle Namen von Ausgabeobjekten in Großbuchstaben umzuwandeln:

type: experimental_object_rewriter
global:
  outputName:
    all:
      case: UPPERCASE

Entitätsauswahl

Wenn Sie entitätsspezifische Transformationen ausführen möchten, geben Sie die SQL-Quellentität in der Konfigurationsdatei an. Alle match-Attribute sind optional. Verwenden Sie nur die match-Attribute, die für eine Transformation erforderlich sind. Das Feld match wird mit den Namen der Quellobjekte verglichen, nachdem alle konfigurierten defaultDatabase- und schemaSearchPath-Werte aufgelöst wurden, außer in outputName-Regeln, wenn auch global.outputName konfiguriert ist. Weitere Informationen finden Sie unter Ausgabenamenszuordnung. In der folgenden YAML-Konfigurationsdatei werden Attribute enthüllt, die zugeordnet werden sollen, um bestimmte Entitäten auszuwählen:

match:
  database: <literal_name>
  schema: <literal_name>
  relation: <literal_name>
  attribute: <literal_name>
  databaseRegex: <regex>
  schemaRegex: <regex>
  relationRegex: <regex>
  attributeRegex: <regex>

Beschreibung der einzelnen match-Attribute:

database oder db: Entspricht dem Namen der Quelldatenbank, der der Komponente project_id in BigQuery entspricht.
schema: entspricht dem Namen des Quellschemas, der der Komponente dataset in BigQuery entspricht.
relation: entspricht dem Namen der Quelltabelle oder -ansicht.
attribute: Entspricht dem Namen der Quellspalte. Diese Property ist nur für die Auswahl von attribute gültig.
databaseRegex oder dbRegex: Gleicht den gesamten database-Namen mit einem regulären Ausdruck ab, bei dem die Groß-/Kleinschreibung nicht berücksichtigt wird.
schemaRegex: gleicht den gesamten schema-Namen mit einem regulären Ausdruck ab, bei dem die Groß-/Kleinschreibung nicht berücksichtigt wird.
relationRegex: Gleicht den gesamten relation-Namen mit einem regulären Ausdruck ab, bei dem die Groß-/Kleinschreibung nicht berücksichtigt wird.
attributeRegex: Gleicht den gesamten attribute-Namen mit einem regulären Ausdruck ab, bei dem die Groß-/Kleinschreibung nicht berücksichtigt wird. Diese Property ist nur für die Auswahl von attribute gültig.

In der folgenden YAML-Konfigurationsdatei werden beispielsweise die match-Attribute angegeben, um die Tabelle testdb.acme.employee für eine temporäre Tabellentransformation auszuwählen.

type: object_rewriter
relation:
-
  match:
    database: testdb
    schema: acme
    relation: employee
  temporary: true

Sie können die Attribute databaseRegex, schemaRegex, relationRegex und attributeRegex verwenden, um reguläre Ausdrücke anzugeben und eine Teilmenge von Entitäten auszuwählen. Im folgenden Beispiel werden alle Beziehungen vom tmp_schema-Schema in testdb zu temporär geändert, solange ihr Name mit tmp_ beginnt:

type: object_rewriter
relation:
-
  match:
    schema: tmp_schema
    relationRegex: "tmp_.*"
  temporary: true

Sowohl bei Literal- als auch bei regex-Attributen wird die Groß- und Kleinschreibung nicht berücksichtigt. Sie können die Groß-/Kleinschreibung erzwingen, indem Sie einen regex mit einem deaktivierten i-Flag verwenden, wie im folgenden Beispiel gezeigt:

match:
  relationRegex: "(?-i:<actual_regex>)"

Sie können vollständig qualifizierte Entitäten auch mit einer entsprechenden Kurzstring-Syntax angeben. Eine Kurzstring-Syntax erwartet genau 3 (für die Beziehungsauswahl) oder 4 (für die Attributauswahl) Namenssegmente, die durch Punkte getrennt sind, wie im Beispiel testdb.acme.employee. Die Segmente werden dann intern so interpretiert, als wären sie database, schema, relation und attribute respektive übergeben worden. Das heißt, dass Namen exakt abgeglichen werden. Daher sind reguläre Ausdrücke in der abgekürzten Syntax nicht zulässig. Das folgende Beispiel zeigt die Verwendung der Kurzstring-Syntax, um eine vollständig qualifizierte Entität in einer YAML-Konfigurationsdatei anzugeben:

type: object_rewriter
relation:
-
  match: "testdb.acme.employee"
  temporary: true

Wenn eine Tabelle einen Punkt im Namen enthält, können Sie den Namen nicht in einer abgekürzten Syntax angeben. In diesem Fall müssen Sie einen Objekt-Abgleich verwenden. Im folgenden Beispiel wird die Tabelle testdb.acme.stg.employee zu temporär geändert:

type: object_rewriter
relation:
-
  match:
    database: testdb
    schema: acme
    relation: stg.employee
  temporary: true

In einer YAML-Konfigurationsdatei wird auch key als Alias für match akzeptiert. Sowohl key als auch match unterstützen explizite Unterfelder für Namenskomponenten sowie die durch Punkte getrennte Kurzstring-Syntax "database.schema.relation" oder "database.schema.relation.attribute". Gemäß Konvention wird key häufig mit der Syntax für kurze Strings und match mit expliziten Unterfeldern verwendet.

Standarddatenbank

Einige SQL-Eingabedialekte, insbesondere Teradata, unterstützen keinen Datenbanknamen in qualifizierten Kennungen (schema.table). Verwenden Sie in diesem Fall ein Objekt match und lassen Sie das Attribut database weg. Alternativ können Sie defaultDatabase konfigurieren, z. B. unter type: environment, damit Sie in Objekt- oder Kurzstring-match-Regeln einen Abgleich mit dieser Standarddatenbank durchführen können.

Unterstützte Zielattributtypen

Sie können die YAML-Konfigurationsdatei verwenden, um Attributtyp-Transformationen durchzuführen, bei denen Sie den Datentyp einer Spalte vom Quelltyp in einen Zieltyp transformieren. Die YAML-Konfigurationsdatei unterstützt die folgenden Zieltypen:

BOOLEAN
TINYINT
SMALLINT
INTEGER
BIGINT
FLOAT
DOUBLE
NUMERIC (Unterstützt optionale Genauigkeit und Skalierung, z. B. NUMERIC(18, 2))
TIME
TIMETZ
DATE
DATETIME
TIMESTAMP
TIMESTAMPTZ
CHAR (Unterstützt optionale Genauigkeit, z. B. CHAR(42))
VARCHAR (Unterstützt optionale Genauigkeit, z. B. VARCHAR(42))

Beispiele für YAML-Konfigurationen

Dieser Abschnitt enthält Beispiele zum Erstellen verschiedener YAML-Konfigurationsdateien für Ihre SQL-Übersetzungen. In jedem Beispiel wird die YAML-Syntax zum Transformieren Ihrer SQL-Übersetzung auf bestimmte Weisen beschrieben, und zwar mit einer kurzen Beschreibung. Jedes Beispiel enthält auch den Inhalt einer teradata-input.sql- oder hive-input.sql-Datei und einer bq-output.sql-Datei, sodass Sie die Auswirkungen einer Konfigurations-YAML in einer BigQuery-SQL-Abfrageübersetzung vergleichen können.

In den folgenden Beispielen wird Teradata oder Apache Hive als SQL-Eingabedialekt und BigQuery-SQL als Ausgabedialekt verwendet.

Objektnamen ändern

Mit der folgenden YAML-Konfigurationsdatei wird die Groß-/Kleinschreibung von SQL-Objektnamen in UPPERCASE oder LOWERCASE geändert. Sie können case für all-Objekte festlegen oder für bestimmte Objekttypen (database, schema, relation, attribute, function, sequence, index, variable oder projection) überschreiben:

type: experimental_object_rewriter
global:
  outputName:
    all:
      case: UPPERCASE
    database:
      case: LOWERCASE
    attribute:
      case: LOWERCASE

Eine SQL-Übersetzung mit dieser YAML-Konfigurationsdatei könnte so aussehen:

`teradata-input.sql`	create table TESTDB.testschema.x(A int); select * from TESTDB.testschema.x;
`bq-output.sql`	CREATE TABLE testdb.TESTSCHEMA.X ( a INT64 ) ; SELECT X.* FROM testdb.TESTSCHEMA.X ;

Tabelle temporär machen

Mit der folgenden YAML-Konfigurationsdatei wird eine reguläre Tabelle in eine temporäre Tabelle umgewandelt:

type: object_rewriter
relation:
  -
    match: "testdb.testschema.x"
    temporary: true

Eine SQL-Übersetzung mit dieser YAML-Konfigurationsdatei könnte so aussehen:

`teradata-input.sql`	create table testdb.testschema.x(a int);
`bq-output.sql`	CREATE TEMPORARY TABLE x ( a INT64 ) ;

Tabelle sitzungsspezifisch machen

Mit der folgenden YAML-Konfigurationsdatei wird eine reguläre Tabelle in eine sitzungsspezifische Tabelle mit einer Ablaufzeit von 60 Sekunden geändert.

type: object_rewriter
relation:
  -
    match: "testdb.testschema.x"
    ephemeral:
      expireAfterSeconds: 60

Eine SQL-Übersetzung mit dieser YAML-Konfigurationsdatei könnte so aussehen:

`teradata-input.sql`	create table testdb.testschema.x(a int);
`bq-output.sql`	CREATE TABLE testdb.testschema.x ( a INT64 ) OPTIONS( expiration_timestamp=timestamp_add(current_timestamp(), interval 60 SECOND) );

Partitionsablauf festlegen

Mit der folgenden Konfigurations-YAML-Datei wird der Ablauf einer partitionierten Tabelle in 1 Tag geändert:

type: object_rewriter
relation:
  -
    match: "testdb.testschema.x"
    partitionLifetime:
      expireAfterSeconds: 86400

Eine SQL-Übersetzung mit dieser YAML-Konfigurationsdatei könnte so aussehen:

`teradata-input.sql`	create table testdb.testschema.x(a date, b int) partition by (a);
`bq-output.sql`	CREATE TABLE testdb.testschema.x ( a DATE, b INT64 ) PARTITION BY a OPTIONS( partition_expiration_days=1 );

Externen Speicherort oder Format für eine Tabelle ändern

Mit der folgenden YAML-Konfigurationsdatei werden der externe Speicherort und das Format für eine Tabelle geändert:

type: object_rewriter
relation:
  -
    match: "testdb.testschema.x"
    external:
      locations: "gs://path/to/department/files"
      format: ORC

Eine SQL-Übersetzung mit dieser YAML-Konfigurationsdatei könnte so aussehen:

`teradata-input.sql`	create table testdb.testschema.x(a int);
`bq-output.sql`	CREATE EXTERNAL TABLE testdb.testschema.x ( a INT64 ) OPTIONS( format='ORC', uris=[ 'gs://path/to/department/files' ] );

Tabellenbeschreibung festlegen oder ändern

Mit der folgenden YAML-Konfiguration wird die Beschreibung einer Tabelle festgelegt:

type: object_rewriter
relation:
  -
    match: "testdb.testschema.x"
    description:
      text: "Example description."

Eine SQL-Übersetzung mit dieser YAML-Konfigurationsdatei könnte so aussehen:

`teradata-input.sql`	create table testdb.testschema.x(a int);
`bq-output.sql`	CREATE TABLE testdb.testschema.x ( a INT64 ) OPTIONS( description='Example description.' );

Tabellenpartitionierung festlegen oder ändern

Mit der folgenden Konfigurations-YAML-Datei wird das Partitionierungsschema einer Tabelle mithilfe von add, remove oder set geändert, wobei set alle vorhandenen Partitionierungsspalten ersetzt:

type: object_rewriter
relation:
  -
    match: "testdb.testschema.x"
    partition:
      simple:
        add: [a]
  -
    match: "testdb.testschema.y"
    partition:
      simple:
        remove: [a]

Eine SQL-Übersetzung mit dieser YAML-Konfigurationsdatei könnte so aussehen:

teradata-input.sql

    create table testdb.testschema.x(a date, b int);
    create table testdb.testschema.y(a date, b int) partition by (a);

bq-output.sql

    CREATE TABLE testdb.testschema.x
    (
      a DATE,
      b INT64
    )
    PARTITION BY a;
    CREATE TABLE testdb.testschema.y
    (
      a DATE,
      b INT64
    )
    ;

Mit der folgenden Konfigurations-YAML-Datei wird das Partitionierungsschema einer Tabelle so geändert, dass sie nach Bereichs-Bucket partitioniert wird:

type: object_rewriter
relation:
-
  match: "testdb.testschema.mytable"
  partition:
    range_bucket:
      column: "id"
      start: 0
      end: 100
      step: 10
      options:
        require_partition_filter: "TRUE"

Eine SQL-Übersetzung mit dieser YAML-Konfigurationsdatei könnte so aussehen:

snowflake-input.sql

      create table testdb.testschema.mytable (
        date timestamp_ntz,
        id number,
        content variant
      );

bq-output.sql

      CREATE TABLE TESTDB.TESTSCHEMA.MYTABLE
      (
        DATE DATETIME,
        ID INT64,
        CONTENT JSON
      )
      PARTITION BY RANGE_BUCKET(ID, generate_array(0, 100, 10))
      OPTIONS(
        require_partition_filter=TRUE
      );

Tabellen-Clustering festlegen oder ändern

Mit der folgenden YAML-Konfigurationsdatei wird das Clustering-Schema einer Tabelle mithilfe von add, remove oder set geändert, wobei set alle vorhandenen Clustering-Spalten ersetzt:

type: object_rewriter
relation:
  -
    match: "testdb.testschema.x"
    clustering:
      add: [a]
  -
    match: "testdb.testschema.y"
    clustering:
      remove: [b]

Eine SQL-Übersetzung mit dieser YAML-Konfigurationsdatei könnte so aussehen:

hive-input.sql

    create table testdb.testschema.x(a int, b int);
    create table testdb.testschema.y(a int, b int)
      clustered by (b) into 16 buckets;

bq-output.sql

    CREATE TABLE testdb.testschema.x
    (
      a INT64,
      b INT64
    )
    CLUSTER BY a;
    CREATE TABLE testdb.testschema.y
    (
      a INT64,
      b INT64
    )
    ;

Typ eines Spaltenattributs ändern

Mit der folgenden YAML-Konfigurationsdatei wird der Datentyp für ein Attribut einer Spalte geändert:

type: object_rewriter
attribute:
  -
    match:
      database: testdb
      schema: testschema
      attributeRegex: "a+"
    type:
      target: NUMERIC(10,2)

Sie können den Quelldatentyp in einen der unterstützten Zielattributtypen umwandeln.

Eine SQL-Übersetzung mit dieser YAML-Konfigurationsdatei könnte so aussehen:

`teradata-input.sql`	create table testdb.testschema.x(a int, b int, aa int);
`bq-output.sql`	CREATE TABLE testdb.testschema.x ( a NUMERIC(31, 2), b INT64, aa NUMERIC(31, 2) ) ;

Wenn keine direkte Umwandlung zwischen dem Quell- und dem Zieltyp möglich ist, z. B. beim Konvertieren einer INT-Spalte, in der YYYYMMDD-Datumsangaben gespeichert sind, in eine DATE-Spalte, geben Sie GoogleSQL-Konvertierungsausdrücke vom Typ sourceToTarget und targetToSource an. Verwenden Sie ? als Platzhalter für den Spalten- oder Ausdruckswert. Beispiel:

type: object_rewriter
attribute:
  -
    match: "testdb.acme.employee.jd"
    type:
      target: DATE
      sourceToTarget: "parse_date('%Y%m%d', cast(? as string))"
      targetToSource: "cast(format_date('%Y%m%d', cast(? as date)) as int64)"

Eine SQL-Übersetzung mit dieser YAML-Konfigurationsdatei könnte so aussehen:

teradata-input.sql

    create table testdb.acme.employee(eid int, jd int);
    insert into testdb.acme.employee select 42, 20011213;
    select eid, jd from testdb.acme.employee e where jd > 20010101;

bq-output.sql

    CREATE TABLE testdb.acme.employee
    (
      eid INT64,
      jd DATE
    )
    ;
    INSERT INTO testdb.acme.employee
      SELECT
          42,
          parse_date('%Y%m%d', CAST(20011213 as STRING))
    ;
    SELECT
        eid,
        CAST(format_date('%Y%m%d', jd) as INT64) AS jd
      FROM
        testdb.acme.employee AS e
      WHERE CAST(format_date('%Y%m%d', jd) as INT64) > 20010101
    ;

Verbindung zu externem Data Lake hinzufügen

Mit der folgenden YAML-Konfigurationsdatei wird die Quelltabelle als externe Tabelle gekennzeichnet, die auf in einem externen Data Lake gespeicherte Daten verweist. Der Data Lake wird durch eine Data-Lake-Verbindung angegeben.

type: object_rewriter
relation:
-
  match: "testdb.testschema.x"
  external:
    connection_id: "connection_test"

Eine SQL-Übersetzung mit dieser YAML-Konfigurationsdatei könnte so aussehen:

`hive-input.sql`	CREATE TABLE testdb.testschema.x ( a VARCHAR(150), b INT );
`bq-output.sql`	CREATE EXTERNAL TABLE testdb.testschema.x ( a STRING, b INT64 ) WITH CONNECTION `connection_test` OPTIONS( );

Zeichencodierung einer Eingabedatei ändern

Standardmäßig versucht der BigQuery Migration Service, die Zeichencodierung von Eingabedateien automatisch zu erkennen. Wenn der BigQuery Migration Service die Codierung einer Datei falsch erkennt, können Sie die Zeichencodierung mit einer YAML-Konfigurationsdatei explizit angeben.

In der folgenden YAML-Konfigurationsdatei wird die explizite Zeichencodierung der Eingabedatei als ISO-8859-1 angegeben. Sie können Eingabedateien mit einem genauen Pfad (path), einem Glob-Muster (pathGlob) oder einem regulären Ausdruck (pathRegex) abgleichen:

type: input_formats
formats:
- source:
    pathGlob: "*.sql"
  contents:
    raw:
      charset: iso-8859-1

Globale Typkonvertierung

Die folgende YAML-Konfigurationsdatei ändert einen Datentyp in allen Skripts in einen anderen. Außerdem wird ein Quelldatentyp angegeben, der im transpilierten Skript vermieden werden soll. Dies unterscheidet sich von der Konfiguration Spaltenattributstyp ändern, bei der nur der Datentyp für ein einzelnes Attribut geändert wird.

Der Übersetzungsdienst unterstützt die folgenden Datentypkonvertierungen:

DATETIME bis TIMESTAMP
TIMESTAMP nach DATETIME (akzeptiert optionale Zeitzone)
TIMESTAMP WITH TIME ZONE (timestamptz) nach DATETIME (akzeptiert optionale Zeitzone)
CHAR nach VARCHAR (akzeptiert optionale precisionAction und comparisonBehavior)
VARCHAR nach VARCHAR (akzeptiert optionale precisionAction und comparisonBehavior)

Im folgenden Beispiel wandelt die YAML-Konfiguration den Datentyp TIMESTAMP in DATETIME um.

type: experimental_object_rewriter
global:
  typeConvert:
    timestamp: DATETIME

`CHAR`- und `VARCHAR`-Typen konvertieren

In Dialekten wie Teradata werden CHAR(N)-Werte rechts mit Leerzeichen aufgefüllt und String-Schreibvorgänge werden auf die deklarierte Spaltenlänge gekürzt. Bei Stringvergleichen wird standardmäßig nicht zwischen Groß- und Kleinschreibung unterschieden (NOT CASESPECIFIC) und nachgestellte Leerzeichen werden ignoriert. Standardmäßig emuliert die Übersetzungs-Engine diese Semantik in BigQuery. Es fügt Wrapper für das Auffüllen rechts (CONCAT) und das Abschneiden (SUBSTR) bei Umwandlungen und Schreibvorgängen, Wrapper für UPPER und RTRIM bei Vergleichen und Wrapper für UPPER bei GROUP BY-Schlüsseln hinzu.

Sie können die Felder char und varchar unter global.typeConvert mit den folgenden Attributen konfigurieren:

target: Muss auf VARCHAR festgelegt werden. Wenn Sie target: VARCHAR für char konfigurieren, wird der rechte Abstand (CONCAT) von CHAR entfernt, auch wenn precisionAction den Wert PRESERVE hat.
precisionAction: Steuert die Genauigkeit der Zeichenlänge und die SUBSTR-Kürzungswrapper:
- PRESERVE (Standard): Behält die Genauigkeit der Zeichenlänge bei Ausdrücken bei und gibt SUBSTR-Kürzungs-Wrapper aus, wenn in CHAR(N)- oder VARCHAR(N)-Spalten umgewandelt oder eingefügt wird. Wenn Sie auch STRING(N)-Spaltenlängen in CREATE TABLE-DDL ausgeben möchten, lesen Sie den Abschnitt Strenge der String-Präzision festlegen.
- DROP: Verwirft die Genauigkeit der Zeichenlänge bei Ausdrücken und lässt SUBSTR-Kürzungs-Wrapper weg.
comparisonBehavior: Steuert RTRIM- und UPPER-Wrapper für Vergleiche und GROUP BY-Schlüssel. Wenn Sie für char oder varchar einen anderen Wert als STRICT festlegen, gilt dieser für beide Typen. Legen Sie daher für beide Schlüssel denselben Wert fest, wenn Sie beide konfigurieren:
- STRICT (Standard): Emuliert sowohl das Auffüllen mit nachgestellten Leerzeichen (RTRIM) als auch die Sortierung ohne Berücksichtigung der Groß-/Kleinschreibung (UPPER).
- PADDING_AWARE: emuliert nur das Auffüllen mit nachgestellten Leerzeichen (RTRIM) und lässt UPPER weg.
- CASE_AWARE: emuliert nur die Sortierung ohne Berücksichtigung der Groß-/Kleinschreibung (UPPER) und lässt RTRIM weg.
- NONE: Lässt sowohl RTRIM- als auch UPPER-Wrapper weg, sodass die Ausgabe direkte Vergleiche und GROUP BY-Ausdrücke verwendet.

Mit der folgenden YAML-Konfigurationsdatei wird CHAR in VARCHAR konvertiert und die Wrapper für Kürzung (SUBSTR), nachgestellte Leerzeichen (RTRIM) und Groß-/Kleinschreibung (UPPER) für die Spalten CHAR und VARCHAR entfernt:

type: experimental_object_rewriter
global:
  typeConvert:
    char:
      target: VARCHAR
      precisionAction: DROP
      comparisonBehavior: NONE
    varchar:
      target: VARCHAR
      precisionAction: DROP
      comparisonBehavior: NONE

Eine SQL-Übersetzung mit dieser YAML-Konfigurationsdatei könnte so aussehen:

`teradata-input.sql`	create table r(a char(10), b varchar(20)); select cast(b as char(5)) from r where a = b group by 1;
`bq-output.sql`	CREATE TABLE r ( a STRING, b STRING ) ; SELECT b FROM r WHERE a = b GROUP BY 1 ;

Standardzeitzone festlegen

Datenbankdialekte haben unterschiedliche Semantiken und Namen für verschiedene Datums- und Uhrzeitdatentypen. Der Übersetzungsdienst verwendet in seiner YAML-Konfiguration die folgende Terminologie, unabhängig vom Namen des Datentyps des Eingabedialekts:

Ein datetime ist eine Kombination aus Y-M-D H:M:S, die nicht an eine bestimmte Zeitzone gebunden ist. datetime steht für eine Uhrzeit und nicht für einen bestimmten Zeitpunkt.
Ein timestamp steht für einen bestimmten oder absoluten Zeitpunkt und ist daher implizit an eine bestimmte Zeitzone gebunden, die eine Einstellung auf Sitzungsebene oder eine Datenbankeinstellung sein kann.
Ein timestamptz stellt einen bestimmten Zeitpunkt wie ein timestamp dar, hat aber im Gegensatz zu einem timestamp einen bestimmten Zeitzonen-Offset. Obwohl sie denselben Zeitpunkt darstellen, werden 2019-06-01 12:00:00+4 und 2019-06-01 06:00:00-2 als unterschiedliche timestamptz-Werte betrachtet.

In Dialekten wie Teradata geben datums-/uhrzeitbezogene Funktionen wie current_date, current_time oder current_timestamp Zeitstempel basierend auf einem implizit konfigurierten Sitzungszeitzonenparameter zurück. BigQuery gibt hingegen immer Zeitstempel in UTC zurück. Für ein konsistentes Verhalten zwischen den beiden Dialekten muss die Zeitzone entsprechend konfiguriert werden.

Wir empfehlen, die Standardzeitzone für die Übersetzung anzugeben, wenn Ihre Quelldatenbank eine andere Standardzeitzone als UTC hat. So wird die Zeitzone beibehalten und die übersetzte Abfrage funktioniert korrekt.

Im folgenden Beispiel werden in der Konfigurations-YAML-Datei ein TIMESTAMP- und ein TIMESTAMPTZ-Datentyp in DATETIME konvertiert. Die Zielzeitzone ist auf Europe/Paris festgelegt.

Gültige Zeitzonenwerte finden Sie unter Zeitzonen.

type: experimental_object_rewriter
global:
  typeConvert:
    timestamp:
      target: DATETIME
      timezone: Europe/Paris
    timestamptz:
      target: DATETIME
      timezone: Europe/Paris

Eine SQL-Übersetzung mit dieser YAML-Konfigurationsdatei könnte so aussehen:

snowflake-input.sql

      create table x(c_timestamp timestamp_ltz, c_timestamptz timestamp_tz, c_datetime timestamp_ntz);

      select c_timestamp from x where c_timestamp > current_timestamp(0);
      select c_timestamptz from x where c_timestamptz > cast(current_timestamp(0) as timestamp_tz);
      select c_datetime from x where c_datetime > cast(current_timestamp(0) as timestamp_ntz);

bq-output.sql

      CREATE TABLE X
      (
        C_TIMESTAMP DATETIME,
        C_TIMESTAMPTZ DATETIME,
        C_DATETIME DATETIME
      )
      ;
      SELECT
          C_TIMESTAMP
        FROM
          X
        WHERE C_TIMESTAMP > datetime(current_timestamp(), 'Europe/Paris')
      ;
      SELECT
          X.C_TIMESTAMPTZ
        FROM
          X
        WHERE X.C_TIMESTAMPTZ > datetime(current_timestamp(), 'Europe/Paris')
      ;
      SELECT
          C_DATETIME
        FROM
          X
        WHERE C_DATETIME > datetime(current_timestamp(), 'Europe/Paris')
      ;

Im folgenden Beispiel wandelt die YAML-Konfiguration den Datentyp DATETIME in TIMESTAMP um.

Standardmäßig wird TIMESTAMPTZ ohne Konfiguration in TIMESTAMP konvertiert.

type: experimental_object_rewriter
global:
  typeConvert:
    datetime:
      target: TIMESTAMP

Eine SQL-Übersetzung mit dieser YAML-Konfigurationsdatei könnte so aussehen:

snowflake-input.sql

      create table x(c_timestamp timestamp_ltz, c_timestamptz timestamp_tz, c_datetime timestamp_ntz);

      select c_timestamp from x where c_timestamp > current_timestamp(0);
      select c_timestamptz from x where c_timestamptz > cast(current_timestamp(0) as timestamp_tz);
      select c_datetime from x where c_datetime > cast(current_timestamp(0) as timestamp_ntz);

bq-output.sql

      CREATE TABLE X
      (
        C_TIMESTAMP TIMESTAMP,
        C_TIMESTAMPTZ TIMESTAMP,
        C_DATETIME TIMESTAMP
      )
      ;
      SELECT
          C_TIMESTAMP
        FROM
          X
        WHERE C_TIMESTAMP > current_timestamp()
      ;
      SELECT
          C_TIMESTAMPTZ
        FROM
          X
        WHERE C_TIMESTAMPTZ > current_timestamp()
      ;
      SELECT
          X.C_DATETIME
        FROM
          X
        WHERE X.C_DATETIME > current_timestamp()
      ;

Änderung der Abrechnung auswählen

Mit der folgenden YAML-Konfigurationsdatei werden die Klauseln „Sternprojektion“, GROUP BY und ORDER BY in SELECT-Anweisungen geändert.

Das Feld select.starProjection unterstützt die folgenden Werte:

ALLOW: Gibt SELECT * aus, wenn die Quellabfrage SELECT * verwendet oder alle Spalten der Tabelle in der richtigen Reihenfolge auflistet.
PRESERVE (Standard): Gibt SELECT * nur aus, wenn die Quellabfrage SELECT * verwendet.
EXPAND: Erweitert SELECT * in einzelne Spaltenverweise, wenn Tabellenmetadaten verfügbar sind.

Die Felder select.groupBy und select.orderBy unterstützen die folgenden Werte:

EXPRESSION: Formatiert GROUP BY- oder ORDER BY-Elemente als vollständige Ausdrücke.
ALIAS: Formatiert GROUP BY- oder ORDER BY-Elemente mit SELECT-Spalten-Aliassen, sofern verfügbar.
INDEX: Formatiert GROUP BY- oder ORDER BY-Elemente mit 1-basierten Spaltenpositionen, z. B. GROUP BY 1.

Im folgenden Beispiel wird in der YAML-Konfiguration die Sternprojektion auf EXPAND festgelegt.

type: statement_rewriter
select:
  starProjection: EXPAND

Eine SQL-Übersetzung mit dieser YAML-Konfigurationsdatei könnte so aussehen:

`teradata-input.sql`	create table x(a int, b TIMESTAMP); select * from x;
`bq-output.sql`	CREATE TABLE x ( a INT64, b TIMESTAMP ) ; SELECT x.a, x.b FROM x ;

UDF-Spezifikation

In den meisten Fällen kann der BigQuery-SQL-Übersetzer die Datendefinitionssprache (DDL) externer benutzerdefinierter Funktionen (UDFs) automatisch parsen, um ihre Eingabe- und Ausgabedatentypen zu bestimmen, auch wenn der UDF-Text in einer externen Sprache geschrieben ist. Bei bestimmten Quelldialekten kann der Übersetzer die UDF-Signatur jedoch möglicherweise nicht automatisch kompilieren. Damit SQL-Anweisungen, die auf diese UDFs verweisen, korrekt übersetzt werden, ohne dass die ursprüngliche DDL angegeben werden muss, können Sie eine YAML-Konfigurationsdatei verwenden, um die UDF-Signaturen explizit zu registrieren.

In der folgenden YAML-Konfiguration wird die Signatur benutzerdefinierter Funktionen (UDFs) angegeben, die in den Quellskripts verwendet werden. Geben Sie jede Signatur im Quelldialekt als RETURN_TYPE FUNCTION_NAME(ARG_NAME ARG_TYPE, ...) an, einschließlich eines Namens für jeden Parameter. Ähnlich wie Metadaten-ZIP-Dateien können UDF-Definitionen dazu beitragen, eine genauere Übersetzung von Eingabeskripts zu erstellen.

type: metadata
udfs:
  - "date parse_short_date(dt int)"

Eine SQL-Übersetzung mit dieser YAML-Konfigurationsdatei könnte so aussehen:

`teradata-input.sql`	create table x(dt int); select parse_short_date(dt) + 1 from x;
`bq-output.sql`	CREATE TABLE x ( dt INT64 ) ; SELECT date_add(parse_short_date(dt), interval 1 DAY) FROM x ;

Einige Quelldialekte unterstützen UDFs, die einen Namen für verschiedene Argumentsignaturen verwenden. Diese werden manchmal als überladene UDFs bezeichnet. Geben Sie für überladene UDFs udf und ein eindeutiges Ziel name an, damit jede Signatur einem eindeutigen Funktionsnamen in BigQuery zugeordnet wird:

type: metadata
udfs:
  - "int custom_substr(pos int)"
  - udf: "int custom_substr(pos int, len int)"
    name: "custom_substr_with_len"

Kennungsmuster bei der Metadatensuche entfernen

In SQL-Eingabeskripts wird möglicherweise auf Objekte oder Spalten mit einem Präfix, Suffix oder Benennungsmuster verwiesen, das nicht in Ihren Metadatendefinitionen enthalten ist. Beispielsweise wird auf a_dt verwiesen, wenn in der Metadaten-DDL die Spalte dt definiert ist. Verwenden Sie in diesem Fall nameAlias unter type: metadata, damit die Übersetzungs-Engine das Muster beim Suchen nach Objektnamen in Metadaten entfernt. Die ursprüngliche Kennung wird in der SQL-Ausgabe beibehalten.

Das Feld nameAlias unterstützt die folgenden Attribute. Jedes Attribut akzeptiert einen einzelnen String oder eine Liste von Strings. Der erste übereinstimmende Eintrag in jeder Liste wird angewendet:

stripPrefix: Entfernt ein Literalpräfix, bevor Metadaten gesucht werden.
stripSuffix: Entfernt ein literales Suffix, bevor Metadaten gesucht werden.
stripRegex: Stimmt mit einem regulären Ausdruck überein, bei dem die Groß-/Kleinschreibung berücksichtigt wird, und ersetzt jeden übereinstimmenden Teilstring bei der Schnellrecherche von Metadaten durch die erste Erfassungsgruppe (...). Verankern Sie das Muster, z. B. ^a_(.*)$, damit nur ein Präfix oder die vollständige Kennung übereinstimmt.

Mit der folgenden YAML-Konfiguration wird das führende Präfix a_ aus Kennungen entfernt, wenn Objektnamen in Metadaten gesucht werden:

type: metadata
nameAlias:
  stripRegex: "^a_(.*)$"

Eine SQL-Übersetzung mit dieser YAML-Konfigurationsdatei könnte so aussehen:

`teradata-input.sql`	create table t(dt date); select a_dt + 1 from t;
`bq-output.sql`	CREATE TABLE t ( dt DATE ) ; SELECT date_add(a_dt, interval 1 DAY) FROM t ;

Strenge der Dezimalpräzision festlegen

Standardmäßig erhöht der BigQuery Migration Service die numerische Genauigkeit auf die höchste Genauigkeit, die für eine bestimmte Skalierung verfügbar ist. Das folgende Konfigurations-YAML überschreibt dieses Verhalten, indem die Genauigkeitsstriktheit so konfiguriert wird, dass die Dezimalgenauigkeit der Quellanweisung beibehalten wird.

type: statement_rewriter
common:
  decimalPrecision: STRICT

Eine SQL-Übersetzung mit dieser YAML-Konfigurationsdatei könnte so aussehen:

`teradata-input.sql`	create table x(a decimal(3,0));
`bq-output.sql`	CREATE TABLE x ( a NUMERIC(3) ) ;

Strenge der Stringpräzision festlegen

Standardmäßig lässt der BigQuery Migration Service die Stringgenauigkeit beim Übersetzen von CHAR- und VARCHAR-Spalten weg. So können Kürzungsfehler beim Schreiben von Werten vermieden werden. Einige SQL-Dialekte wie Teradata kürzen Werte, die die maximale Genauigkeit beim Schreiben überschreiten, während BigQuery in diesem Szenario einen Fehler zurückgibt.

Wenn Ihre Anwendung nicht auf dem Kürzungsverhalten des Quelldialekts basiert, sollten Sie die Genauigkeit der Spalte in der übersetzten Typdefinition beibehalten.

Das folgende Konfigurations-YAML überschreibt dieses Verhalten, indem die Genauigkeitsstriktheit so konfiguriert wird, dass die Stringgenauigkeit der Quellanweisung beibehalten wird.

type: statement_rewriter
common:
  stringPrecision: STRICT

Eine SQL-Übersetzung mit dieser YAML-Konfigurationsdatei könnte so aussehen:

`teradata-input.sql`	create table x(a varchar(3));
`bq-output.sql`	CREATE TABLE x ( a STRING(3) ) ;

Zuordnung von Ausgabenamen

Sie können type: experimental_object_rewriter in einer YAML-Konfigurationsdatei verwenden, um SQL-Objektnamen (database, schema, relation, attribute, function, sequence, index, variable oder projection) statisch oder dynamisch zuzuordnen:

Jeder Objekttyp erweitert nur seinen eigenen Namen und die Platzhalter der übergeordneten Hierarchie aus ${database}, ${schema}, ${relation}, ${attribute}, ${function}, ${sequence}, ${index}, ${variable} und ${projection}. Beispiel: Eine schema-Regel erweitert ${database} und ${schema}, während eine relation-Regel ${database}, ${schema} und ${relation} erweitert.
Wenn mehrere Regeln desselben Objekttyps mit unterschiedlichen match-Kriterien auf ein Objekt zutreffen, gilt die letzte übereinstimmende Regel in der Liste.
Globale replace- und case-Regeln unter global.outputName werden vor objektspezifischen outputName-Regeln ausgeführt. Eine objektspezifische Regel stimmt überein und kann den global transformierten Namen des Objekts überschreiben. Bei attribute-Regeln vergleicht match den global transformierten attribute-Namen mit den Quellnamen database, schema und relation. Weitere Informationen finden Sie unter Umschreibung des globalen Ausgabenamens.

Weitere Informationen zur Funktionsweise von Namenszuordnungsregeln auf Datenbank-, Schema-, Beziehungs-, Funktions- und Attributebene finden Sie unter SQL-Objektnamen für die Übersetzung zuordnen.

Statische Namenszuordnung

Verwenden Sie die statische Namenszuordnung, um den Namen einer Entität zuzuordnen. Wenn Sie nur bestimmte Teile des Namens ändern, aber andere Teile des Namens beibehalten möchten, fügen Sie nur die Teile ein, die geändert werden müssen.

Mit der folgenden YAML-Konfigurationsdatei wird der Name der Tabelle von my_db.my_schema.my_table in my_new_db.my_schema.my_new_table geändert.

type: experimental_object_rewriter
relation:
-
  match: "my_db.my_schema.my_table"
  outputName:
    database: "my_new_db"
    relation: "my_new_table"

Eine SQL-Übersetzung mit dieser YAML-Konfigurationsdatei könnte so aussehen:

`teradata-input.sql`	create table my_db.my_schema.my_table(a int);
`bq-output.sql`	CREATE TABLE my_new_db.my_schema.my_new_table ( a INT64 ) ;

Sie können die statische Namenszuordnung verwenden, um die Region zu aktualisieren, die von Namen in den öffentlichen benutzerdefinierten Funktionen verwendet wird.

Im folgenden Beispiel werden die Namen in der UDF bqutil.fn von der standardmäßigen multiregionalen us-Region in die Region europe_west2 geändert:

type: experimental_object_rewriter
function:
-
  match:
    database: bqutil
    schema: fn
  outputName:
    database: bqutil
    schema: fn_europe_west2

Dynamische Namenszuordnung

Mit der dynamischen Namenszuordnung können Sie mehrere Objekte gleichzeitig ändern und neue Namen basierend auf den zugeordneten Objekten erstellen.

Mit der folgenden YAML-Konfigurationsdatei wird der Name aller Tabellen geändert, indem das Präfix stg_ zu den Tabellen hinzugefügt wird, die zum Schema staging gehören. Anschließend werden diese Tabellen in das Schema production verschoben.

type: experimental_object_rewriter
relation:
-
  match:
    schema: staging
  outputName:
    schema: production
    relation: "stg_${relation}"

Eine SQL-Übersetzung mit dieser YAML-Konfigurationsdatei könnte so aussehen:

`teradata-input.sql`	create table staging.my_table(a int);
`bq-output.sql`	CREATE TABLE production.stg_my_table ( a INT64 ) ;

Spaltennamenzuordnung

Verwenden Sie den Abschnitt attribute unter type: experimental_object_rewriter, um Spalten sowohl in Tabellendefinitionen als auch in Abfrageverweisen umzubenennen:

type: experimental_object_rewriter
attribute:
-
  match:
    relation: employee
    attributeRegex: "\\d.*"
  outputName:
    attribute: "col_${attribute}"

Eine SQL-Übersetzung mit dieser YAML-Konfigurationsdatei könnte so aussehen:

`teradata-input.sql`	create table employee(eid int, "2name" varchar(10)); select eid, "2name" from employee e;
`bq-output.sql`	CREATE TABLE employee ( eid INT64, col_2name STRING ) ; SELECT eid, col_2name FROM employee AS e ;

Standard-Datenbank und Schemasuchepfad angeben

In der folgenden YAML-Konfigurationsdatei werden eine Standarddatenbank und ein Schemasuchpfad angegeben.

type: environment
session:
  defaultDatabase: myproject
  schemaSearchPath: [myschema1, myschema2]

Eine SQL-Übersetzung mit dieser YAML-Konfigurationsdatei könnte so aussehen:

`teradata-input.sql`	SELECT * FROM mydb.mytable; SELECT * FROM table1;
`bq-output.sql`	SELECT * FROM myproject.mydb.mytable; SELECT * FROM myproject.myschema1.table1;

Einstellen von `NLS_DATE_FORMAT`

Mit der folgenden YAML-Konfiguration wird der Parameter NLS_DATE_FORMAT auf das Format DD/MM/YYYY festgelegt. Wir empfehlen, NLS_DATE_FORMAT für die implizite Verwendung von Datumsformaten und Umwandlungen anzugeben. Wenn keine Angabe erfolgt, wird das Standardformat für die Übersetzung, DD-MON-RR, verwendet.

type: environment
session:
  dateFormat: DD/MM/YYYY

Eine SQL-Übersetzung mit dieser YAML-Konfigurationsdatei könnte so aussehen:

oracle-input.sql

    create table x(dt date default '31/12/1999');
    insert into x values ('01/01/2000');

bq-output.sql

      CREATE TABLE X
      (
        DT DATETIME DEFAULT DATETIME '1999-12-31 00:00:00'
      )
      ;
      INSERT INTO X
        VALUES (DATETIME '2000-01-01 00:00:00')
      ;

Umschreibung des globalen Ausgabenamens

In der folgenden YAML-Konfiguration werden replace-Regeln unter global.outputName verwendet, um die Ausgabenamen aller Objekte (all) oder bestimmter Objekttypen (database, schema, relation, attribute, function, sequence, index, variable oder projection) umzuschreiben. Jede Regel entspricht einem regulären Ausdruck, bei dem die Groß-/Kleinschreibung beachtet wird, und ersetzt Übereinstimmungen durch neuen Text, einschließlich $0, $1 und anderer Erfassungsgruppen.

Globale outputName-Transformationen (replace gefolgt von case) werden vor objektspezifischen outputName-Regeln wie schema, relation oder attribute ausgeführt. Eine objektspezifische Regel stimmt mit dem global transformierten Namen des Objekts überein und kann diesen überschreiben. Bei attribute-Regeln vergleicht match den global transformierten attribute-Namen mit den Quellnamen database, schema und relation:

type: experimental_object_rewriter
global:
  outputName:
    all:
      replace:
        - regex: '\s'
          replaceWith: '_'
        - regex: '>='
          replaceWith: 'gte'
        - regex: '^[^a-zA-Z_].*'
          replaceWith: '_$0'

Eine SQL-Übersetzung mit dieser YAML-Konfigurationsdatei könnte so aussehen:

`teradata-input.sql`	create table "test special chars >= 12"("42eid" int, "custom column" varchar(10));
`bq-output.sql`	CREATE TABLE test_special_chars_gte_12 ( _42eid INT64, custom_column STRING ) ;

Leistung von übersetztem SQL optimieren und verbessern

Optionale Transformationen können auf übersetztes SQL angewendet werden, um Änderungen einzuführen, die die Leistung oder die Kosten verbessern können. Diese Optimierungen sind strikt von der Groß- und Kleinschreibung abhängig und sollten daher anhand der unveränderten SQL-Ausgabe bewertet werden, um ihre tatsächliche Auswirkung auf die Leistung zu ermitteln.

Mit der folgenden YAML-Konfiguration werden optionale Transformationen aktiviert. Jeder Eintrag in der Liste transformations unterstützt die folgenden Felder:

name: der Name der Optimierung.
enabled (optional): Ein boolescher Wert, der standardmäßig auf true gesetzt ist. Setzen Sie enabled auf false, um eine Optimierung zu deaktivieren, die standardmäßig für den Quelldialekt aktiviert ist.
parameters (optional): Eine Zuordnung optimierungsspezifischer Parameter.

type: optimizer
transformations:
  - name: PRECOMPUTE_INDEPENDENT_SUBSELECTS
  - name: REWRITE_CTE_TO_TEMP_TABLE
    parameters:
      threshold: 1

Optimierung	Optionaler Parameter	Beschreibung
`PRECOMPUTE_INDEPENDENT_SUBSELECTS`	`scope: [PREDICATE, PROJECTION]`	Schreibt die Abfrage um, indem eine `DECLARE`-Anweisung hinzugefügt wird, um einen Ausdruck in `PREDICATE`-Klauseln, `PROJECTION`-Klauseln oder beiden durch eine vorausberechnete Variable zu ersetzen. Durch diese Umschreibung wird der Ausdruck in ein statisches Prädikat umgewandelt, wodurch die Menge der gelesenen Daten reduziert werden kann. Der Parameter `scope` akzeptiert eine Liste, die `PREDICATE`, `PROJECTION` oder beides enthält. Wenn `parameters` weggelassen wird, ist der Standardwert für `scope` `[PREDICATE]`, was die Klauseln `WHERE` und `JOIN ON` abdeckt. Wenn Sie eine skalare Unterabfrage in eine `DECLARE`-Anweisung extrahieren, wird das ursprüngliche Prädikat statisch und kann daher für eine verbesserte Ausführungsplanung verwendet werden. Durch diese Optimierung werden neue SQL-Anweisungen eingeführt.
`REWRITE_CTE_TO_TEMP_TABLE`	`threshold: N`	Schreibt allgemeine Tabellenausdrücke (CTEs) in temporäre Tabellen um, wenn mindestens `N` Verweise auf denselben CTE vorhanden sind. Durch diese Neuschreibung wird die Abfragekomplexität reduziert und die einmalige Ausführung des CTE erzwungen. Wenn `N` weggelassen wird, ist der Standardwert `4`. Wir empfehlen diese Optimierung, wenn nicht triviale CTEs mehrmals referenziert werden. Die Einführung von temporären Tabellen hat einen Overhead, der höher sein kann als die Ausführung mehrerer CTEs mit geringer Komplexität oder Kardinalität. Durch diese Optimierung werden neue SQL-Anweisungen eingeführt.
`REWRITE_ZERO_SCALE_NUMERIC_AS_INTEGER`	`bigint: N`	`NUMERIC/BIGNUMERIC`-Attribute mit Nullskala werden in den Typ `INT64` umgeschrieben, wenn die Genauigkeit innerhalb von `N` liegt. Wenn `N` weggelassen wird, ist der Standardwert `18`. Wir empfehlen diese Optimierung bei der Übersetzung von Quelldialekten, die keine Ganzzahltypen haben. Wenn Sie Spaltentypen ändern, müssen Sie alle nachgelagerten Verwendungen auf Typkompatibilität und semantische Änderungen prüfen. Beispiel: Bruchteilungen werden zu Ganzzahldivisionen, Code, der numerische Werte erwartet. Bei Snowflake-Übersetzungen ist diese Optimierung für numerische Werte ohne Dezimalstellen bis zu einer Genauigkeit von 38 standardmäßig aktiviert. Diese Optimierung sorgt dafür, dass ein Snowflake-`INTEGER`, der in Snowflake implizit als `NUMBER(38,0)` dargestellt wird, in einen BigQuery-`INT64` anstelle eines `BIGNUMERIC(38)` übersetzt wird. Wenn Ihre Anwendung Zahlen mit einer Genauigkeit von mehr als 18 Stellen verwendet, empfehlen wir, diese Funktion zu deaktivieren, damit BigQuery den gesamten Wertebereich verarbeiten kann, den Ihre Anwendung benötigt.
`DROP_TEMP_TABLE`		Fügt `DROP TABLE`-Anweisungen für alle temporären Tabellen hinzu, die in einem Script erstellt und bis zum Ende nicht gelöscht wurden. Dadurch wird der Abrechnungszeitraum für die temporäre Tabelle von 24 Stunden auf die Ausführungszeit des Skripts reduziert. Wir empfehlen diese Optimierung, wenn nach dem Ende der Skriptausführung nicht auf temporäre Tabellen zugegriffen wird, um weitere Verarbeitungsschritte auszuführen. Durch diese Optimierung werden neue SQL-Anweisungen eingeführt.
`REGEXP_CONTAINS_TO_LIKE`		Schreibt einige Kategorien von `REGEXP_CONTAINS`-Übereinstimmungsmustern in `LIKE`-Ausdrücke um. Wir empfehlen diese Optimierung, wenn kein anderer Prozess wie der Makroersatz darauf angewiesen ist, dass die regulären Ausdrucksmusterliterale unverändert in der Ausgabe-SQL-Anweisung beibehalten werden.
`ADD_DISTINCT_TO_SUBQUERY_IN_SET_COMPARISON`		Fügt Unterabfragen eine `DISTINCT`-Klausel hinzu, die als Wert für den `[NOT] IN`-Operator verwendet werden. Wir empfehlen diese Optimierung, wenn die Kardinalität (bestimmte Anzahl von Werten) des Unterabfrageergebnisses deutlich niedriger als die Anzahl der Werte ist. Wenn diese Voraussetzung nicht erfüllt ist, kann sich diese Transformation negativ auf die Leistung auswirken.
`APPROXIMATE_RANGE_PARTITIONS`		Nähert nicht zusammenhängende oder nicht reguläre Ganzzahlpartitionierungsschemas an, indem sie in zusammenhängende, gleich große Partitionsbereiche konvertiert werden, die von BigQuery unterstützt werden. Standardmäßig haben solche Partitionierungsschemas keinen Einfluss auf das Tabellenpartitionierungsschema in übersetzten DDL-Anweisungen. Wir empfehlen diese Optimierung, wenn die Quelltabelle eine nicht zusammenhängende Partitionierungsfunktion wie die Teradata-Funktion `RANGE_N` verwendet und von einem gleich großen Partitionierungsschema in BigQuery profitieren würde.

Beispiele für Optimierungen

Bei der folgenden Optimierung werden numerische Typen ohne Dezimalstellen mit einer Genauigkeit von maximal 38 in BigQuery in INT64 konvertiert.

# An INTEGER is internally represented as NUMBER(38,0) in Snowflake.
# To convert Snowflake INTEGER to INT64 in BigQuery, enable the rewrite for precision <= 38.
# Note that this can produce incorrect results if your application logic uses more than 18 digits of precision.
#
# This configuration is enabled by default for the Snowflake Dialect.
type: optimizer
transformations:
  - name: REWRITE_ZERO_SCALE_NUMERIC_AS_INTEGER
    parameters:
      bigint: 38

Eine SQL-Übersetzung mit dieser Optimierung könnte so aussehen:

`snowflake-input.sql`	CREATE TABLE numbers(i INTEGER, n NUMERIC(10,0));
`bq-output.sql`	CREATE TABLE NUMBERS ( I INT64, N INT64 ) ;

Mit der folgenden Konfiguration wird die Optimierung in Dialekten wie Snowflake deaktiviert, in denen sie standardmäßig aktiviert ist. Bei dieser Konfiguration werden numerische Typen je nach Eingabegenauigkeit in NUMERIC oder BIGNUMERIC konvertiert, anstatt in den Standardwert INT64.

type: optimizer
transformations:
  - name: REWRITE_ZERO_SCALE_NUMERIC_AS_INTEGER
    enabled: false

Eine SQL-Übersetzung mit dieser Optimierung könnte so aussehen:

`snowflake-input.sql`	CREATE TABLE numbers(i INTEGER, n NUMERIC(10,0));
`bq-output.sql`	CREATE TABLE NUMBERS ( I BIGNUMERIC(38), N NUMERIC(29) ) ;

Gemini-basierte YAML-Konfigurationsdatei erstellen

Wenn Sie KI-Ausgaben generieren möchten, müssen Sie mindestens eine *.ai_config.yaml-Datei angeben und Gemini AI-Vorschläge aktivieren, wenn die Benutzeroberfläche dies erfordert. Weitere Informationen finden Sie unter Konfigurationsdateien für eine Übersetzung bereitstellen.

Voraussetzungen

Die YAML-Konfigurationsdatei für KI-Ausgaben muss das Suffix .ai_config.yaml haben. Beispiel: rules_1.ai_config.yaml.

Unterstützte Felder

Im Gegensatz zu einer *.config.yaml-Datei enthält eine *.ai_config.yaml-Datei keinen type-Header. Stattdessen enthält die Datei eine übergeordnete translation_rules-Liste, in der jede Regel die folgenden Felder unterstützt:

suggestion_type (optional): Geben Sie den Typ des KI-Vorschlags an, der generiert werden soll. Die folgenden Vorschlagstypen werden unterstützt:
- QUERY_CUSTOMIZATION (Standard): Generiert KI-Vorschläge für SQL-Code basierend auf den in der Datei *.ai_config.yaml angegebenen Übersetzungsregeln.
- TRANSLATION_EXPLANATION: Generiert Text, der eine Zusammenfassung der übersetzten GoogleSQL-Abfrage sowie die Unterschiede und Inkonsistenzen zwischen der SQL-Abfrage und der übersetzten GoogleSQL-Abfrage enthält.
rewrite_target (optional): Geben Sie SOURCE_SQL an, um die Regel auf die ursprüngliche SQL-Eingabe anzuwenden, bevor die Übersetzungs-Engine ausgeführt wird, oder TARGET_SQL, um die Regel auf die übersetzte SQL-Ausgabe anzuwenden, die die Übersetzungs-Engine erzeugt. Der Standardwert ist TARGET_SQL. Weitere Informationen finden Sie unter Anwendung der beiden Regelarten.
instruction (optional): Beschreiben Sie in natürlicher Sprache die Änderung, die auf die Eingabe-SQL oder die übersetzte SQL für QUERY_CUSTOMIZATION-Regeln angewendet werden soll, oder die Erklärung, die für TRANSLATION_EXPLANATION-Regeln generiert werden soll.
examples (optional): Geben Sie eine Liste von input- und output-SQL-Paaren an, die zeigen, wie ein SQL-Muster geändert werden soll.

Sie können bei Bedarf weitere translation_rules und zusätzliche examples hinzufügen.

Beispiele

In den folgenden Beispielen werden Gemini-basierte YAML-Konfigurationsdateien erstellt, die Sie für Ihre SQL-Übersetzungen verwenden können.

Entfernen Sie die Funktion „upper“ in der Standardabfrage für die Übersetzungsausgabe.

translation_rules:
- instruction: "Remove upper() function"
  examples:
  - input: "upper(X)"
    output: "X"

Mehrere Übersetzungsregeln erstellen, um die Übersetzungsausgabe anzupassen

translation_rules:
- instruction: "Remove upper() function"
  suggestion_type: QUERY_CUSTOMIZATION
  rewrite_target: TARGET_SQL
  examples:
  - input: "upper(X)"
    output: "X"
- instruction: "Insert a comment at the head that explains each statement in detail."
  suggestion_type: QUERY_CUSTOMIZATION
  rewrite_target: TARGET_SQL

SQL-Kommentare aus der Eingabeabfrage für die Übersetzung entfernen

translation_rules:
- instruction: "Remove all the sql comments in the input sql query."
  suggestion_type: QUERY_CUSTOMIZATION
  rewrite_target: SOURCE_SQL

Übersetzungserklärungen mit dem Standard-LLM-Prompt generieren

In diesem Beispiel werden die vom Übersetzungsdienst bereitgestellten Standard-LLM-Prompts verwendet, um Texterklärungen zu generieren:

translation_rules:
- suggestion_type: "TRANSLATION_EXPLANATION"

Generiert Erklärungen für Übersetzungen mithilfe Ihrer eigenen Prompts in natürlicher Sprache

translation_rules:
- suggestion_type: "TRANSLATION_EXPLANATION"
  instruction: "Explain the syntax differences between the source Teradata query and the translated GoogleSQL query."

Mehrere Vorschlagstypen in einer einzigen YAML-Konfigurationsdatei

translation_rules:
- suggestion_type: "TRANSLATION_EXPLANATION"
  instruction: "Explain the syntax differences between the source Teradata query and the translated GoogleSQL query."
- instruction: "Remove upper() function"
  suggestion_type: QUERY_CUSTOMIZATION
  rewrite_target: TARGET_SQL
  examples:
  - input: "upper(X)"
    output: "X"
- instruction: "Remove all the sql comments in the input sql query."
  suggestion_type: QUERY_CUSTOMIZATION
  rewrite_target: SOURCE_SQL

Mehrere YAML-Konfigurationen anwenden

Wenn Sie eine einzelne Abfrage oder Batch-SQL-Dateien übersetzen, können Sie mehrere YAML-Konfigurationsdateien in einem einzelnen Übersetzungsjob angeben, um verschiedene Transformationen widerzuspiegeln. Wenn mehrere Konfigurationen miteinander in Konflikt stehen, kann eine Transformation eine andere überschreiben. Wir empfehlen, in jeder Datei unterschiedliche Arten von Konfigurationseinstellungen zu verwenden, um widersprüchliche Transformationen im selben Übersetzungsjob zu vermeiden.

Im folgenden Beispiel werden zwei separate YAML-Konfigurationsdateien aufgelistet, die für einen einzelnen SQL-Übersetzungsjob bereitgestellt wurden. Eine zum Ändern des Attributs einer Spalte und eine, um die Tabelle als temporär zu bestimmen:

change-type-example.config.yaml:

type: object_rewriter
attribute:
  -
    match: "testdb.testschema.x.a"
    type:
      target: NUMERIC(10,2)

make-temp-example.config.yaml:

type: object_rewriter
relation:
  -
    match: "testdb.testschema.x"
    temporary: true

Eine SQL-Übersetzung mit diesen beiden YAML-Konfigurationsdateien könnte so aussehen:

`teradata-input.sql`	create table testdb.testschema.x(a int);
`bq-output.sql`	CREATE TEMPORARY TABLE x ( a NUMERIC(31, 2) ) ;

SQL-Übersetzungen mit YAML transformieren

Arten von YAML-Konfigurationsdateien

Anwendung der beiden Regeltypen

Konfigurationsdateien für eine Übersetzung bereitstellen

Console

gcloud

API

MCP

Wo finde ich die Übersetzungsausgaben?

Anforderungen an die Übersetzungsdatei für *.config.yaml

Richtlinien zum Erstellen einer YAML-Konfigurationsdatei

Header

Entitätsauswahl

Standarddatenbank

Unterstützte Zielattributtypen

Beispiele für YAML-Konfigurationen

Objektnamen ändern

Tabelle temporär machen

Tabelle sitzungsspezifisch machen

Partitionsablauf festlegen

Externen Speicherort oder Format für eine Tabelle ändern

Tabellenbeschreibung festlegen oder ändern

Tabellenpartitionierung festlegen oder ändern

Tabellen-Clustering festlegen oder ändern

Typ eines Spaltenattributs ändern

Verbindung zu externem Data Lake hinzufügen

Zeichencodierung einer Eingabedatei ändern

Globale Typkonvertierung

CHAR- und VARCHAR-Typen konvertieren

Standardzeitzone festlegen

Änderung der Abrechnung auswählen

UDF-Spezifikation

Kennungsmuster bei der Metadatensuche entfernen

Strenge der Dezimalpräzision festlegen

Strenge der Stringpräzision festlegen

Zuordnung von Ausgabenamen

Statische Namenszuordnung

Dynamische Namenszuordnung

Spaltennamenzuordnung

Standard-Datenbank und Schemasuchepfad angeben

Einstellen von NLS_DATE_FORMAT

Umschreibung des globalen Ausgabenamens

Leistung von übersetztem SQL optimieren und verbessern

Beispiele für Optimierungen

Gemini-basierte YAML-Konfigurationsdatei erstellen

Voraussetzungen

Unterstützte Felder

Beispiele

Entfernen Sie die Funktion „upper“ in der Standardabfrage für die Übersetzungsausgabe.

Mehrere Übersetzungsregeln erstellen, um die Übersetzungsausgabe anzupassen

SQL-Kommentare aus der Eingabeabfrage für die Übersetzung entfernen

Übersetzungserklärungen mit dem Standard-LLM-Prompt generieren

Generiert Erklärungen für Übersetzungen mithilfe Ihrer eigenen Prompts in natürlicher Sprache

Mehrere Vorschlagstypen in einer einzigen YAML-Konfigurationsdatei

Mehrere YAML-Konfigurationen anwenden

Anforderungen an die Übersetzungsdatei für `*.config.yaml`

`CHAR`- und `VARCHAR`-Typen konvertieren

Einstellen von `NLS_DATE_FORMAT`