Tips for writing SQL

Einleitung

Diese Seite enthält Tipps und Tricks zum Schreiben von SQL-Umwandlungen.

Allgemein

• In Unions müssen die Namen und die Reihenfolge der Felder genau übereinstimmen. Es kann erforderlich sein, leere Felder in Teilen der Union zu erstellen, um alle Felder mit der select -Anweisung null as "Field_X" .
• Beim Schreiben von dbt für SQL Server werden alle Jinja-Anweisungen in SQL-Code kompiliert, unabhängig davon, ob sie sich in SQL-Kommentaren befinden oder nicht. Im folgenden -- {{ ref('Table1') }} wird beispielsweise Jinja in SQL-Code kompiliert.
• Runden Sie keine Zahlen, da dies zu Inkonsistenzen führen kann. Die Plattform führt dies automatisch aus, wenn ein Anzeigewert dies erfordert.

Transformationsstruktur

In SQL können nicht alle Transformationen in derselben Tabelle berechnet werden. Grund dafür können Aggregate oder Eigenschaften sein, die nicht in einer einzigen Auswahlanweisung ausgedrückt werden können. Zu diesem Zweck können Sie unterstützende Tabellen erstellen. Durch das Erstellen einer unterstützenden Tabelle in der Datenbank können Sie das Modell in mehreren Transformationen verwenden. Ist die Wiederverwendung des Modells nicht erforderlich, kann die unterstützende Transformation auch als Vorverarbeitungsabfrage in die bestehende Tabelle eingefügt werden.

Um zwischen unterstützenden Transformationen und den anderen Transformationen zu unterscheiden, können Sie sie in einem separaten Unterverzeichnis gruppieren.

Leistung

So beschleunigen Sie Ihre Abfrageausführung:

• Vermeiden Sie select distinct , wo es auch möglich ist, ein Aggregat zu erstellen, und verwenden Sie nur einen Datensatz mit einer where -Klausel.
• Verwenden Sie union all anstelle von union . Mit union all werden Datensätze aus Tabellen verkettet, während union Duplikate entfernt.
• Wenn Sie an einem großen Dataset arbeiten, können Sie die Daten begrenzen, mit denen Sie während der Entwicklung arbeiten.
• Alle Modelle (mit Ausnahme der Modelle im Verzeichnis 1_input ) werden von dbt als Tabelle materialisiert. Dies ist die Standardeinstellung für alle Process Mining-Connectors. Weitere Informationen finden Sie in der dbt- Dokumentation zu Materialisierungen.
• Verwenden Sie beim Generieren eines ID-Felds das Makro id() , das in pm-utilsverfügbar ist. Beispiele finden Sie im devkit-connector.

SQL-Formatordnung

Der folgende Formatvorlagen Guide wurde verwendet, um die Process Mining -App-Vorlagen zu entwickeln. Es wird empfohlen, diese Richtlinien für die Konsistenz und Lesbarkeit zu befolgen.

• Schreiben Sie SQL-Befehle und -Funktionen in Kleinbuchstaben.
• Verwenden Sie dieselbe Einzugebene für select, from, where, join usw., um die Struktur des Modells besser zu verstehen.
  • Verwenden Sie Einzüge für die Verwendung von Funktionen, wenn dies die Lesbarkeit verbessert. Verwenden Sie beispielsweise einen Einzug für jede Anweisung in einer case-Funktion.

• Verwenden Sie konsistente Namenskonventionen für Tabellen und Felder, um SQL-Fehler zu vermeiden, die darauf hinweisen, dass Tabellen oder Felder in der Datenbank nicht vorhanden sind. Halten Sie sich an die folgenden Richtlinien:

  • Tabellen und Felder beginnen mit einem Großbuchstaben.
  • Verwenden Sie einen Unterstrich _ zwischen separaten Wörtern in Tabellen und Feldern.
  • Alle Felder haben Anführungszeichen.
  • Tabellen enthalten keine Anführungszeichen. Dadurch wird die Lesbarkeit in Kombination mit Feldern mit Anführungszeichen verbessert.
• Allen Feldern wird die Tabelle vorangestellt, aus der sie stammen, um das Modell leichter zu verstehen und zu erweitern.
• Kommas zur Trennung von Feldern werden am Ende der Zeile platziert.
• Verwenden Sie Inline-Kommentare, wenn bestimmte Konstruktionen erklärt werden müssen. Stellen Sie anschließend sicher, dass der Kommentar einen Mehrwert bietet.
• Verwenden Sie aus Gründen der Lesbarkeit und Wartbarkeit explizite Select-Anweisungen im Transformationsteil der Abfrage und nicht select * . Insbesondere bei Unions kann die Verwendung von select * zu Fehlern führen.