Keep a large SQL script library under control

Nützliche Abfragen verschwinden. Man schreibt ein Statement, das die Daten genau so zurückgibt, wie man sie braucht, schließt den Editor, und drei Wochen später muss man dieselbe Frage erneut stellen, und das Statement ist verschwunden. Es könnte im Clipboard-Verlauf sein, oder in einem alten Skript-File, oder in einem Email-Thread, aber es ist nicht dort, wo man es braucht, wenn man es braucht.

Der Script Manager ist die Antwort: ein Ort zum Speichern von SQL-Statements, die man wiederholen wird, organisiert nach Namespace, Server oder als globale Bibliothek, mit Ordnern für Kategorisierung. Es ist kein vollständiges Versionskontrollsystem — es ist eine geordnete Ablage für wiederverwendbare Abfragen.

Drei Arten von Skripten: Namespace, Server, Global

Skripte können in drei Bereichen gespeichert werden:

• Namespace-spezifisch — Skripte, die nur für einen spezifischen Namespace sinnvoll sind, wie eine Abfrage, die eine Tabelle erwähnt, die nur in diesem Namespace existiert. Diese erscheinen unter dem Namespace-Knoten im Script Manager.
• Server-spezifisch — Skripte, die für jeden Namespace auf einem Server funktionieren, aber nicht auf anderen Servern. Diese erscheinen unter dem Server-Knoten.
• Global — Skripte, die überall funktionieren, wie eine generische SELECT COUNT(*) FROM table_name oder eine Abfrage, die man auf mehrere Server anwendet. Diese erscheinen im Global-Bereich, getrennt von jeder Verbindung.

Die Trennung ist wichtig, weil sie verhindert, dass Skripte, die nur in einem Kontext sinnvoll sind, in der Liste für alle anderen Kontexte erscheinen. Ein Skript, das SQLUser.Person abfragt, macht keinen Sinn in einem Namespace, der dieses Schema nicht hat, also sollte es nicht in der Liste erscheinen.

Ordner für Kategorisierung

Skripte können in Ordnern organisiert werden, und Ordner können verschachtelt werden. Das ist nützlich, wenn man zwanzig Skripte für dieselbe Anwendung hat — einen „Patient Queries"-Ordner, einen „Billing Reports"-Ordner, einen „Performance Checks"-Ordner — sodass verwandte Skripte zusammen stehen, nicht in einer flachen Liste.

Ordner sind optional. Wenn man nur fünf Skripte hat, ist eine flache Liste in Ordnung. Wenn man fünfzig hat, sind Ordner die Antwort.

Schnellzugriff aus dem SQL-Editor

Der Script Manager ist nicht ein separates Fenster, das man öffnen und schließen muss. Er ist ein Panel neben dem SQL-Editor, immer sichtbar, sodass man ein Skript mit einem Klick laden kann. Ein Skript auswählen lädt seinen Text in den Editor, bereit zum Ausführen oder Bearbeiten.

Das ist die häufigste Arbeitsweise: den Editor öffnen, ein Skript laden, ein paar Parameter ändern, F5 drücken. Das Skript ist die Vorlage, nicht der endgültige Text, also ist das Laden nicht dasselbe wie das Ausführen — es ist der Startpunkt für die Bearbeitung.

Skripte bearbeiten, umbenennen, löschen

Skripte können im Manager bearbeitet werden: Rechtsklick, Edit Script, den Text ändern, speichern. Das ist für kleine Änderungen — eine Tabellennamen-Korrektur, eine Spalte hinzufügen — nicht für große Umschreibungen. Für große Änderungen ist es besser, das Skript in den Editor zu laden, es dort zu bearbeiten und dann als neues Skript zu speichern.

Skripte können auch umbenannt und gelöscht werden. Umbenennen ist nützlich, wenn die Beschreibung nicht mehr passt — „Temp Query" wird zu „Patient Last Visit Report" — und Löschen ist für Skripte, die nicht mehr verwendet werden.

Import und Export

Skripte können als SQL-Dateien exportiert werden, sodass man sie in einem Versionskontrollsystem speichern, sie mit anderen teilen oder sie als Backup archivieren kann. Der Export ist eine einfache SQL-Datei, keine proprietäre Struktur, also ist sie lesbar in jedem Texteditor.

Import funktioniert umgekehrt: eine SQL-Datei auswählen, und sie wird als neues Skript in den Manager geladen. Das ist nützlich, um ein Skript von einem anderen Rechner oder von einem Kollegen zu übernehmen.

Wie das zur Versionskontrolle passt

Der Script Manager ist kein Ersatz für Git oder ein anderes Versionskontrollsystem. Er verfolgt keine Historie, er hat kein Branching, er hat kein Merging. Was er tut, ist, die Skripte, die man häufig verwendet, organisiert und abrufbar zu halten, sodass sie nicht im Clipboard-Verlauf verloren gehen.

Für Skripte, die Teil der Anwendung sind — gespeicherte Prozeduren, Migrations-Skripte, Schema-Änderungen — ist Versionskontrolle die richtige Antwort, und diese Skripte sollten in einem Repository leben, nicht im Script Manager. Für Ad-hoc-Analysen, wiederverwendbare Abfragen und einmalige Reports ist der Script Manager die richtige Antwort.

Skripte mit Variablen (Named User+)

In den Editionen Named User, Team und Enterprise unterstützt der SQL-Editor Variablen-Deklarationen, sodass man ein Skript mit einem Parameter schreiben kann, diesen Parameter einmal am Anfang deklariert, und der Editor ersetzt ihn, bevor die Abfrage ausgeführt wird.

Das macht Skripte wiederverwendbarer: Statt zehn Kopien desselben Skripts mit verschiedenen hartkodierten Werten, ein Skript mit einer Variablen, und man ändert die Variable jedes Mal, wenn man es ausführt. Variablen-Skripte können im Script Manager gespeichert werden, genau wie normale Skripte, und sie werden als Vorlage geladen, bereit zur Bearbeitung.

Der Script Manager ist in jeder Edition verfügbar, einschließlich der Free Edition. Laden Sie SQL DATA LENS herunter und speichern Sie Ihre erste wiederverwendbare Abfrage, bevor sie im Clipboard-Verlauf verschwindet.