One SQL statement across namespaces, servers and databases

Die Frage hat fast immer dieselbe Form: Sind diese beiden Dinge gleich? Die Patienten-IDs im klinischen Namespace und die im Abrechnungs-Namespace. Die Artikelnummern in der Produktion und die im Testsystem, das jemand letzten Monat wiederhergestellt hat. Die Codes in IRIS und die Codes in der CSV-Datei, die ein Lieferant gemailt hat. Das ist eine Fünf-Minuten-Frage und ein Join würde sie beantworten — außer dass die beiden Tabellen in verschiedenen Namespaces liegen, oder auf verschiedenen Servern, oder in verschiedenen Produkten, und IRIS joinen über keines davon wird.

Die üblichen Antworten sind alle serverseitig, und sie alle benötigen jemandes Erlaubnis. Query Cloud ist die clientseitige Antwort.

Your sources — unchanged, nothing installed on any of them

• InterSystems IRIS Server A · namespace CLINICAL clinical_Patient
• InterSystems IRIS Server B · namespace BILLING billing_Invoice
• Microsoft SQL Server reporting · schema dbo dbo_Article
• CSV file on your desktop supplier_csv

Read through the connections you already have — read-only, at execution time, and only the rows the statement actually needs

Your workstation

Query Cloud — a local virtual database

• Catalog — connection, schema and table name per registered table. No rows are copied when you add one.
• Query engine — joins, filters and aggregates the fetched rows in memory on this machine.

No row is sent to any public cloud service, and no server is asked for a privilege you do not already have.

One statement, one result set

PatientID	LastName	InvoiceNo	Amount
10432	Meier	2026-0871	1 240.00
10432	Meier	2026-0902	3 118.50
10877	Sarközy	2026-0913	1 004.90

Eine lokale virtuelle Datenbank

Query Cloud verhält sich wie eine lokale virtuelle Datenbank. Darin schreibt man gewöhnliches SQL — Joins, Aggregationen, Subqueries — gegen Tabellen, die physisch an verschiedenen Orten leben, als wären sie alle im selben Namespace. Man verschiebt die Daten nicht zuerst an einen gemeinsamen Ort, und man baut kein Staging-Schema für eine Frage, die man einmal stellen wird.

Der Name ist es wert, klar zu sein, denn „Cloud" bedeutet hier das Gegenteil von dem, was es normalerweise tut. Keine Daten werden an irgendeinen öffentlichen Cloud-Service gesendet. Jede Abfrage und jede Zeile wird lokal von SQL DATA LENS auf Ihrem Arbeitsplatz verarbeitet. Der einzige Netzwerkverkehr ist derselbe Verkehr, den Ihre normalen Verbindungen bereits machen: SQL DATA LENS liest von jedem Quellserver.

Eine Tabelle hinzufügen kostet einen Menüpunkt

Gehen Sie zu einer Quelltabelle irgendwo im Server Navigator und wählen Sie Add table to query cloud…. Wiederholen Sie das für jede Tabelle, die Sie kombinieren möchten. Das ist das gesamte Setup.

Keine Daten werden kopiert, wenn Sie eine Tabelle hinzufügen. Query Cloud speichert nur die Information darüber, woher diese Tabelle kommt — die Verbindung, das Schema und den Tabellennamen. Zeilen werden gelesen, wenn ein Statement ausgeführt wird, und nur die Zeilen, die dieses Statement benötigt.

Einmal registriert, werden die Tabellen wie jede andere adressiert:

SELECT p.PatientID, p.LastName, b.InvoiceNo, b.Amount
FROM   clinical_Patient  p
JOIN   billing_Invoice   b ON b.PatientRef = p.PatientID
LEFT   JOIN supplier_csv s ON s.Code = b.ArticleCode
WHERE  b.Amount > 1000
ORDER  BY b.Amount DESC

Hier könnten clinical_Patient und billing_Invoice auf zwei IRIS-Servern in zwei Rechenzentren sein, und supplier_csv könnte eine Datei auf Ihrem Desktop sein.

Welche Quellen Sie mischen können

• Mehrere Namespaces auf einem Server — der häufigste Fall und derjenige, den IRIS ohne serverseitige Konfiguration am schwersten macht.
• Mehrere IRIS- oder Caché-Server — Produktion gegen Test, eine Site gegen eine andere, eine aktuelle Instanz gegen ein wiederhergestelltes Backup.
• Verschiedene Datenbankprodukte — Microsoft SQL Server, PostgreSQL, MariaDB, SQLite, H2, Access, Trino und der Rest der unterstützten Systeme, gejoint mit IRIS im selben Statement.
• Flat Files — eine CSV-Datei, ein Ordner mit CSV-Dateien oder ein ZIP-Archiv als Tabellen behandelt. Das Abgleichen einer IRIS-Tabelle gegen eine Tabelle, die ein Lieferant geschickt hat, ist der mit Abstand am meisten nachgefragte Anwendungsfall dieses Features.

Wie sich das von den serverseitigen Optionen unterscheidet

Es gibt drei etablierte Wege, über Quellen hinweg in diesem Ökosystem abzufragen. Sie sind alle gute Techniken, und es ist wert zu wissen, wo jede gewinnt.

Linked Server

Microsoft SQL Server, Microsoft Access, Sybase und andere können eine fremde Tabelle in die aktuelle Serverinstanz linken, wonach man Abfragen schreibt, als ob die Tabelle lokal gespeichert wäre. Es vermeidet, Daten woanders hinzuladen, und es funktioniert gut — für die Produkte, die es haben.

Das IRIS und Caché SQL Gateway

Das SQL Gateway gibt IRIS Zugriff auf externe Datenbanken über JDBC oder ODBC, was dieselbe Idee wie ein Linked Server ist. Man erstellt eine Gateway-Verbindung, dann verwendet man einen Wizard im Management Portal, um eine Tabelle oder View in einer ODBC- oder JDBC-konformen Datenbank zu linken: eine Klasse wird generiert, die alle Aufrufe an die externe Tabelle umleitet, und von da an kann IRIS sie abfragen.

Die Einschränkungen sind aber real. Der Benutzer muss berechtigt sein, das SQL Gateway zu verwenden, Verbindungen zu erstellen und Klassen und Tabellen zu erstellen. Und jede Tabelle in der FROM-Klausel einer einzelnen Abfrage muss aus derselben Datenquelle kommen — Abfragen, die heterogene Quellen joinen, sind nicht erlaubt. Das schließt genau die Abgleichsabfragen aus, für die man es wollte. SQL DATA LENS kann serverseitige SQL Gateway-Verbindungen für Sie auflisten, erstellen und löschen, einschließlich der Erstellung einer aus einer Verbindung, die Sie bereits lokal konfiguriert haben — siehe die Administrations-Ansichten.

Mapped Tables (nur Caché)

Das Mapped-Tables-Feature, geerbt von Caché Monitor, ist so etwas wie das SQL Gateway und der Caché Link Table Wizard kombiniert: Es mappt den Datenspeicher einer Klasse oder Tabelle in einen anderen Namespace, sodass man sie neben lokalen Tabellen abfragen kann, als ob sie dort leben würde.

Zwei Vorbehalte. Es funktioniert nur für Caché, und es muss auf dem Server konfiguriert werden. Wichtiger: Behandeln Sie Löschvorgänge auf einer gemappten Tabelle mit großer Vorsicht: Die Originaltabelle und die gemappte Tabelle teilen sich denselben Datenspeicher, also löscht ein Delete durch das Mapping die echten Daten.

Der ehrliche Trade-off

Was die drei serverseitigen Techniken teilen, ist, dass der Datenbankserver die Arbeit macht. Der Query Optimizer wählt einen Plan, der Join läuft, wo die Daten leben, und nur das Ergebnis geht über das Kabel zum Client. Aus reiner Performance-Sicht ist das die bessere Architektur, und für eine Abfrage, die jede Nacht gegen Millionen von Zeilen läuft, ist es die richtige Wahl.

Aber wenn das, was man will, eine Ad-hoc-Abfrage über einige Datenbanken zur Analyse ist, lassen einen alle drei zuerst die Konfiguration machen — und jemanden dazu bringen, einem die Rechte zu geben. Mit Query Cloud kann man Daten aus jeder Quelle kombinieren, zu der man bereits Zugriff hat. Eine funktionierende Verbindung in SQL DATA LENS ist die einzige Anforderung: keine speziellen Berechtigungen und nichts, was auf der Serverseite installiert ist.

Die Kosten sind das Spiegelbild, allerdings geringer als früher. Filter, Joins und Aggregationen werden in jede Quelle hineingeschoben, sofern diese Quelle sie ausführen kann — über das Kabel geht dann nur noch der Teil, der wirklich zusammengeführt werden muss. Show Federation Plan im SQL-Editor zeigt genau, was hineingeschoben wurde und was nicht. Was sich nicht hineinschieben lässt, läuft auf Ihrem Arbeitsplatz, der dafür Speicher und CPU stellt. Das macht Query Cloud weiterhin zu einer schlechten Wahl für das Joinen zweier Tabellen mit jeweils zehn Millionen Zeilen und zu einer ausgezeichneten für schnelle Ad-hoc-Analysen über Systeme hinweg, ohne Daten zu verschieben. Eine föderierte Abfrage ist standardmäßig auf 100.000 Zeilen gedeckelt; dieser Deckel, das Abfrage-Timeout und die Verbindungsgrenzen je Quelle sind konfigurierbar.

Wenn die Antwort ist „diese Zeilen müssen dauerhaft dort hin", dann ist das richtige Tool gar kein Join — es ist der Data Pumper, der Daten von einer Tabelle in eine andere zwischen Namespaces, Servern und verschiedenen Datenbanksystemen kopiert, ohne einen Export-und-Import-Umweg.

Damit anfangen

Registrieren Sie die beiden Verbindungen, die Sie vergleichen möchten, fügen Sie eine Tabelle von jeder hinzu, und schreiben Sie den Join im SQL-Editor, als ob sie schon immer Nachbarn gewesen wären. Nichts ändert sich auf irgendeinem Server, also gibt es keine Aufräumarbeiten danach und keinen Grund, um Erlaubnis zu bitten, es auszuprobieren. Es benötigt überhaupt keinen serverseitigen Fußabdruck.

Die Query Cloud ist ein kostenpflichtiges Feature. In der Free Edition bleibt der Knoten sichtbar, die Verbindung wird aber mit einem Hinweis auf die benötigte Edition abgewiesen. Eine Named-User- oder Team-Lizenz föderiert bis zu fünf Datenbankquellen gleichzeitig, Enterprise hat kein Limit. Deaktivierte Quellen und CSV- oder DBF-Ordnerquellen zählen nicht mit, und der 30-Tage-Test, der jedem Download beiliegt, föderiert mit der Named-User-Grenze. Siehe Preise für die Editionen.