SQL-Editor & Stored Procedures
Stand
Zu SQL View oder Stored Procedure greift ein Architekt in dem Moment, in dem der grafische View Builder die Logik nicht mehr ausdrücken kann — Window Functions, rekursive Hierarchien, transaktionales ETL mit Rollback. Die Weichenstellung, die Erfahrene von Einsteigern trennt, ist nicht ob SQL geschrieben wird, sondern in welcher HANA-Objektfamilie: eine schlecht gewählte Cursor-Schleife macht aus einem Ladevorgang über 100.000 Konten 100.000 Round-Trips, und eine Stored Procedure ohne Checkpoint-Logik macht aus einem 15-minütigen Fehlschlag einen kompletten Nachverarbeitungsvorfall, den das Finance-Team des Kunden zu sehen bekommt. Wird die Wahl SQL-View-vs-Procedure-vs-Table-Function richtig getroffen, skaliert eine Transformation bis zur Fact-Tabelle mit einer Milliarde Zeilen; wird sie falsch getroffen, sättigt sie während einer Go-live-Woche einen produktiven, gemeinsam genutzten HANA-Cloud-Tenant. Dieses Modul vermittelt die Arbeitsdisziplin für diese Entscheidung — keine Syntaxtour.
Was Sie lernen
- Ein realistisches Szenario durcharbeiten: Das Finance-Team eines europäischen Industrieausrüstungsherstellers braucht Multi-Currency-, Multi-Ledger-P&L-Reporting in Datasphere.
- Das Antimuster erkennen und vermeiden: Cursor-pro-Schlüssel-Schleife statt eines mengenbasierten JOIN — 100.000 Accounts werden zu 100.000 Round-Trips.
- Die Kernentscheidung des Moduls anwenden: SQL View vs. grafische View vs. Stored Procedure — SQL View wählen für Window Functions, Mengenoperationen und rekursive CTEs, die read-only bleiben.
- Beherrschung mit dem KPI verfolgen: Qualität des Query-Plans (Ziel: 0 vollständige COLUMN TABLE SCAN auf Tabellen >10 Mio. Zeilen ohne filterndes Prädikat).
SQL Editor & Stored Procedures in Datasphere and HANA Cloud
Der SQL-Editor und die Stored Procedures von Datasphere sind das Schlupfloch für Logik, die der grafische View Builder nicht ausdrücken kann — und für erfahrene Architekten sind sie das primäre Werkzeug für performancekritische Transformationen, komplexe Geschäftsregeln und wiederverwendbare prozedurale Logik. Zwei Objektfamilien sind relevant, und sie sind nicht dasselbe: SQL Views (deklarativ, SELECT-basiert, Teil des semantischen Modells von Datasphere) und SQLScript-Prozeduren / Table Functions (imperativ oder mengenbasiert, aufgerufen aus Data Flows oder Task Chains). Zu verstehen, wann welche greift — und das dahinterliegende HANA-Cloud-Ausführungsmodell — macht den Unterschied zwischen Transformationen, die auf Milliarden von Zeilen skalieren, und solchen, die unter Last zusammenbrechen.
Voraussetzungen
- Mittlere praktische Erfahrung in SAP-Analytics-Projekten
- Zunächst die Kernkonzepte durcharbeiten: C008, C004, C006
Lernergebnisse
- Ein realistisches Szenario durcharbeiten: Das Finance-Team eines europäischen Industrieausrüstungsherstellers braucht Multi-Currency-, Multi-Ledger-P&L-Reporting in Datasphere.
- Das Antimuster erkennen und vermeiden: Cursor-pro-Schlüssel-Schleife statt eines mengenbasierten JOIN — 100.000 Accounts werden zu 100.000 Round-Trips.
- Die Kernentscheidung des Moduls anwenden: SQL View vs. grafische View vs. Stored Procedure — SQL View wählen für Window Functions, Mengenoperationen und rekursive CTEs, die read-only bleiben.
- Beherrschung mit dem KPI verfolgen: Qualität des Query-Plans (Ziel: 0 vollständige COLUMN TABLE SCAN auf Tabellen >10 Mio. Zeilen ohne filterndes Prädikat).
Vollständiges Modul für Mitglieder. Das vollständige Modul ergänzt: den Entscheidungsrahmen · das durchgehende Szenario · die KPI-Scorecard · die Anti-Muster · die Codeblöcke · die Wissenskontrolle · die Schemata.
Offene SAP-Projekte
Aktuelle SAP-Analytics-Projekte und Stellen im DACH-Raum: SAP-Analytics-Projekte im DACH-Raum.