Multipath SQL
Konventionelle Herangehensweise: (Temporäre) Tabellen
Sehr oft, wenn eine Auswertung komplex genug ist, wird es sehr schwer, sie in einem einzigen SQL Statement zu formulieren. Die häufig verwendete Lösung in solchen Fällen ist, temporäre Tabellen mit Zwischenergebnissen anzulegen und diese dann zu einem abschließenden Select-Statement zu kombinieren:
-
CREATE TABLE german_cities AS ( SELECT cities.* FROM cities, countries WHERE cities.country_id=countries.country_id AND countries.name='Germany' ); SELECT b.name, c.name, COUNT(*) FROM customer_moves a, german_cities b, german_cities c WHERE a."from" = b.city_id AND a."to" = c.city_id GROUP BY b.name, c.name;
Diese Herangehensweise hat allerdings Ihre Nachteile:
- Der Nutzer / die Anwendung muss dafür sorgen, dass der Namensraum nicht 'zugemüllt' wird, da jede Session ihre eindeutig benannten Tabellen erzeugen muss.
- Filter, die an den abschließenden Select angewandt werden sollen, müssen bereits bei die Erzeugung von temporären Tabellen (manuell) angewandt werden, ansonsten wären sie unnötig groß.
- Bei jeder Änderung der darunterliegenden Daten müssen die (temporären) Tabellen aktualisiert werden, ansonsten kann die Auswertung veraltete Ergebnisse liefern.
Bitte beachten Sie, dass EXASolution das Konzept von temporären Tabellen nicht kennt. Da EXASolution ein In-Memory DBMS ist und ein durchgängiges Transaktionskonzept implementiert, kann jede Tabelle als temporär interpretiert werden, solange sie nicht commited ist.
Wenn sie Multipath SQL mit Hilfe von Zwischentabellen implementieren, empfehlen wir Ihnen, autocommit abzuschalten und die Zwischentabellen zu droppen, wenn Ihre Auswertung fertig ist. Danach ist es 'sicher', eventuelle Änderungen zu commiten.
Bessere Lösung: Views
Die bessere Lösung in einem solchem Fall ist, die temporären Tabellen durch Views zu ersetzen, was folgende Vorteile bringt:
- Der Query-Optimizer kann das 'Big Picture' im abschließenden Select sehen. Er kann ggf. Join-Reihenfolgen ändern oder sogar lokale Bedingungen aus verschiedenen Views in Verbindung bringen.
- Das selbe Prinzip wird bei zusätzlichen Bedingungen im finalen Select angewandt: sie können i.d.R. bis auf die untersten Ebenen propagiert werden, was bereits in sehr früheren Stadien der Queryberechnung eine Reduzierung der Datenmen bewirkt.
- Es gibt keine veralteten Daten. Die Views haben immer Zugriff auf die aktuell gültigen (commited) Daten.
-
CREATE VIEW german_cities AS ( SELECT cities.* FROM cities, countries WHERE cities.country_id=countries.country_id AND countries.name='Germany' ); SELECT b.name, c.name, COUNT(*) FROM customer_moves a, german_cities b, german_cities c WHERE a."from" = b.city_id AND a."to" = c.city_id GROUP BY b.name, c.name;
Im Falle, wenn die Multipath-Query on-the-fly von einer Applikation generiert wird, haben Sie immer noch den Overhead von Viewerstellung und mögliche Konflikte im Namespace.
All-in-one: Named subselects
In solchen Fällen können benannte Subselects (oder Common Table Expressions) eine Lösung für Sie sein.
Im Grunde funktionieren sie ähnlich wie Views, aber sie stellen keine Datenbankobjekte dar, sondern sind ein Teil Ihrer Query. Sie brauchen nicht erstellt, gedroppt oder commited zu werden: kein Overhead und volle Flexibilität.
-
WITH german_cities AS ( SELECT cities.* FROM cities, countries WHERE cities.country_id=countries.country_id AND countries.name='Germany' ) SELECT b.name, c.name, COUNT(*) FROM customer_moves a, german_cities b, german_cities c WHERE a."from" = b.city_id AND a."to" = c.city_id GROUP BY b.name, c.name;
