Wenn ich an PL/SQL denke, ist meine erste Assoziation dazu der Name Steven Feuerstein. Nun denke ich nicht furchtbar oft on PL/SQL, aber wenn der Herr Feuerstein über ein Thema schreibt, dem ich mit einer gewissen Regelmäßigkeit begegne, dann ist das allemal eine Verlinkung und Zusammenfassung der zugehörigen Artikel wert:
- Table Functions: Introduction and Exploration, Part 1: skizziert die vorgesehene Struktur der Artikelserie und erläutert zunächst das Grundkonzept von table functions: der table operator wandelt eine collection in ein relationales Dataset um, so dass man darauf via Select zugreifen kann. Diese Datasets können als Grundlage in (parametrisierten) Views verwendet werden und mit anderen Tabellen/Datasets gejoint werden, man kann die Ergebnisse gruppieren, sortieren etc. In älteren Releases konnten nur nested tables und varrays vom table operator transformiert werden, aber seit 12.1 bieten auch integer-indexed associative arrays eine verwendbare Grundlage. Der Herr Feuerstein erwähnt die einschlägigen Artikel zum Thema von Adrian Billington und Tim Hall, auf die ich hier auch schon häufiger verwiesen habe. Es folgt eine Liste möglicher use cases (inklusive diverser Beispiele dazu):
- Session-spezifische Daten mit Tabellendaten mergen, um die Vorteile Set-orientierter SQL-Operationen zu erhalten.
- Programmatische Erzeugung spezieller Datasets für die Ausgabe.
- Parametrisierte Views.
- Parallelisierte Selects auf der Basis von pipelined table functions.
- Verringerte PGA-Nutzung durch pipelined table functions, da die zugehörigen Collections nicht komplett im Speicher gehalten werden müssen, sondern sukzessive aufgebaut und weiterverarbeitet werden können.
- Table Functions: Returning complex (non-scalar) datasets, part 2: geht über die im ersten Artikel vorgestellten Beispiel mit (skalaren) Einzelwerten hinaus und zeigt den Umgang mit rows, die mehrere unterschiedliche Attribute enthalten. Zunächst zeigt er dabei, wie man es besser nicht machen sollte (z.B. eine Table mit VARCHAR2(4000), deren Ergebnisse über String-Operationen zerlegt werden). Leider steht die plausiblere Lösung, einen PL/SQL record type als Datentyp einer nested table zu verwenden, nicht zur Verfügung, weil SQL an dieser Stelle etwas kleinlich ist. Stattdessen muss man einen object type verwenden, was syntaktisch kaum einen Unterschied macht.
- Table Functions, Part 3a: table functions as parameterized views in the PL/SQL Challenge website: liefert - wie der Name schon andeutet - ein Beispiel für die Verwendung einer table function als parameterized view.
- Table Functions, Part 3b: implementing table functions for PL/SQL Challenge reports: mit einem umfangreichen table function Beispiel.
- Table Functions, Part 4: Streaming table functions: erklärt, wie man table functions in ETL-Operationen zur Abbildung komplexerer Transformationen einsetzen kann. Das Beispiel ist recht umfangreich, endet aber, ehe die pipelined table functions erreicht sind.
Die folgenden Artikel versuche ich hier zu ergänzen, sobald sie folgen.
Keine Kommentare:
Kommentar veröffentlichen