SAP Handledning för HANA SQL-skript: Syntax och exempel

⚡ Smart sammanfattning

SQL-skript i SAP HANA utökar standard SQL med funktionella och procedurella konstruktioner. Den driver lagrade procedurer och användardefinierade funktioner, och flyttar dataintensiv logik från applikationsservern till databasen.

  • 🧩 Kärndefinition: En samling tillägg till SQL som används inuti lagrade procedurer istället för vanliga SQL-uttryck.
  • 📦 Två containrar: Procedurer beskriver en sekvens av transformationer; användardefinierade funktioner finns i skalär och tabellform.
  • 🧠 Deklarativ logik: Definierar tabelltyper utan att referera till databastabeller och utfärdar vanliga SELECT-satser.
  • 🎼 Orkestreringslogik: Implementerar dataflöde med DDL-, DML- och frågesatser plus loopar och villkor.
  • 🔀 Imperativ logik: IF-, ELSEIF-, ELSE-, CASE-, FOR-loopar och undantagshantering delar logik över dataflöden.
  • 📤 Flera utgångar: En SQL-skriptprocedur returnerar flera resultat via OUTPUT-parametrar, till skillnad från en vanlig SQL-procedur.
  • Parallell utförande: Oberoende satser exekveras parallellt av beräkningsmotorn.

SQL-skript i SAP HANA

Vad är SQL-skript?

SQL Script är en samling av tillägg till SQL. Den kan användas i lagrad procedur istället för vanlig SQL. Det bestämmer de funktionella och procedurmässiga tilläggen.

In SQL Skriptanvändare kan definiera lokala variabler för struktur och tabeller som främst används för att skapa en lagrad procedur.

SQL-skript kan också användas i beräkningsvy. I SQL Script finns det två olika logikbehållare-

  • Procedur (Procedurer låter dig beskriva en sekvens av datatransformationer på data som skickas som indata och databastabeller).
  • Användardefinierad funktion (behållaren för användardefinierad funktion är uppdelad i skalär användardefinierad funktion och tabell användardefinierad funktion).

SQL Script Language-element är enligt nedan –

Deklarativ SQL-skriptlogik (funktionellt tillägg)

  • Det tillåter definition av tabelltyper utan att referera till databastabeller.
  • Typiskt påstående som SELECT.
  • Beräkningsmotorfunktioner (CE).

⚠️ Versionsinformation: Beräkningsmotorns planoperatorer, CE_-funktionerna som CE_COLUMN_TABLE och CE_JOIN, är föråldrade av SAPNy utveckling bör använda standard SQL-satser, vilka optimeraren hanterar minst lika bra. Befintlig CE-kod körs fortfarande men bör migreras nästa gång en procedur ändras.

Orchestration SQL Script Logic (funktionellt tillägg)

Orkestreringslogik används för att implementera dataflöde genom att använda DDL-, DML- och SQL-frågesatser och styrflödeslogik med hjälp av imperativa språkkonstruktioner som loopar och villkor.

  • Data Definition Language Statement. T.ex. Skapa schema.
  • Datamanipulationsspråk (t.ex. infoga).

Imperativ SQL Script Logic (Procedurförlängning)

Imperativ logik delar upp logiken mellan flera dataflöden. T.ex. IF, ELSEIF, ELSE, CASE, FOR (Loop) och Exceptions.

Vikten av SQL-skript

Endast SQL Script tillhandahåller de nödvändiga elementen för att migrera dataintensiv logik eller driften av applikationsservern till databasservern.

Nyckelpunkter i SQL-skript

  • SQL Script exekveras och bearbetas i beräkningsmotorn i HANA-databasen.
  • SQL Script kan utföra komplexa beräkningar.
  • I SQL Script kan en lokal variabel deklareras för att hålla delresultatet.
  • SQL Script Procedur kan returnera fler resultat genom att använda "OUTPUT Parameter" medan Normal SQL Procedur kan returnera endast en.
  • I SQL Script kan du definiera globala eller lokala tabelltyper som kan användas som parametrar.

Genom att använda SQL-skript kan parallellbearbetningsläge uppnås.

Exempel på SQL-skriptprocedur

En procedur är den vanligaste behållaren. Exemplet nedan läser medarbetardata, filtrerar den och returnerar resultatet via en utdatatabellparameter.

CREATE PROCEDURE DHK_SCHEMA.GET_HIGH_EARNERS (
  IN  im_min_salary DECIMAL(15,2),
  OUT ex_employees  TABLE (EMP_NAME NVARCHAR(100), SALARY DECIMAL(15,2)),
  OUT ex_row_count  INTEGER
)
LANGUAGE SQLSCRIPT
READS SQL DATA
AS
BEGIN
  -- Declarative logic: a table variable, not a physical table
  lt_all = SELECT EMP_NAME, SALARY
             FROM DHK_SCHEMA.EMPLOYEE
            WHERE SALARY >= :im_min_salary;

  -- Imperative logic: branch on the result
  SELECT COUNT(*) INTO ex_row_count FROM :lt_all;

  IF :ex_row_count = 0 THEN
    ex_employees = SELECT '' AS EMP_NAME, 0 AS SALARY FROM DUMMY WHERE 1 = 0;
  ELSE
    ex_employees = SELECT * FROM :lt_all ORDER BY SALARY DESC;
  END IF;
END;

Tre konventioner är värda att notera. Ett kolon prefixerar varje läsning av en variabel, så :lt_all läser tabellvariabeln medan lt_all till vänster tilldelar den. READS SQL DATA talar om för optimeraren att proceduren inte har några biverkningar, vilket möjliggör mer aggressiv parallellisering. Och en procedur som returnerar flera utdataparametrar är precis den funktion som vanlig SQL saknar.

Att kalla det är enkelt:

CALL DHK_SCHEMA.GET_HIGH_EARNERS (50000, ?, ?);

Skalära och tabellbaserade användardefinierade funktioner

När en procedur utför åtgärder returnerar en funktion ett värde och kan användas i en fråga. SQL-skript erbjuder två former och de är inte utbytbara.

Parameter Skalär UDF Tabell-UDF
Returer Ett enda värde En resultatuppsättning
Använd i SELECT-lista, WHERE-klausul, uttryck FROM-klausulen, som en tabell
Kan ändra data Nej Nej
Typisk användning Återanvändbar beräkning, till exempel en skattesats Parameteriserad vy som returnerar filtrerade rader
-- Scalar function: returns one value
CREATE FUNCTION DHK_SCHEMA.ADD_BONUS (im_salary DECIMAL(15,2))
  RETURNS total DECIMAL(15,2)
  LANGUAGE SQLSCRIPT AS
BEGIN
  total := :im_salary * 1.10;
END;

SELECT EMP_NAME, DHK_SCHEMA.ADD_BONUS(SALARY) AS WITH_BONUS
  FROM DHK_SCHEMA.EMPLOYEE;

En tabellfunktion definieras med RETURNS TABLE och efterfrågas sedan i FROM-klausulen, vilket gör det till det naturliga sättet att bygga en återanvändbar, parametriserad datamängd som en beräkningsvy eller rapporten kan konsumera.

Bästa praxis för SQL-skript

SQL-skript presterar bra när det skrivs för att låta motorn parallellisera, och dåligt när det skrivs som applikationskod. Sex vanor gör skillnaden.

  1. Föredra deklarativ framför imperativ. En sats baserad på en enda mängd överträffar en loop som bearbetar rader en i taget, ofta med flera storleksordningar. Använd endast en FOR-loop när logiken verkligen inte kan uttryckas som en mängdoperation.
  2. Undvik markörer. De tvingar fram rad-för-rad-bearbetning och omintetgör beräkningsmotorn helt. Nästan varje markör kan skrivas om som en join eller en aggregering.
  3. Håll uttalanden oberoende. Två tabellvariabler som inte refererar till varandra beräknas parallellt. Att kedja varje steg genom det föregående serialiserar hela proceduren.
  4. Deklarera READS SQL DATA där det är sant. Det signalerar att proceduren inte har några biverkningar, vilket möjliggör ytterligare optimering.
  5. Filtrera så tidigt som möjligt. Att minska antalet rader i den första tabellvariabeln krymper allt nedströms, medan filtrering i slutet redan har betalat kostnaden.
  6. Migrera bort från CE_-funktioner. De är föråldrade, kan inte blandas fritt med SQL i en och samma sats, och SQL-optimeraren hanterar nu samma arbete bättre.

Syntax på satsnivå behandlas i SAP HANA SQL, funktionerna som är tillgängliga inom en procedur i SAP HANA SQL-funktioneroch modelleringsobjekten som använder dessa procedurer i SAP HANA-modellering handledning.

Vanliga frågor

Kolonet markerar en läsning av variabeln. Att skriva den utan kolon till vänster tilldelar den, så de två formerna låter parsern skilja tilldelning från referens.

Nej. Planoperatorer i Calculation Engine är föråldrade. Befintlig kod fortsätter att köras, men ny utveckling bör använda standard-SQL, vilket optimeraren nu hanterar minst lika bra.

Ofta ja. Många FOR-loopar och markörer uttrycker en join eller en aggregering skriven på lång sikt, och AI kan föreslå den uppsättningsbaserade motsvarigheten. Verifiera att radantalet matchar innan du använder det.

Ja. Läser planenViz trace, AI identifierar den sats som förbrukar tid och om stegen serialiserades av ett onödigt beroende mellan tabellvariabler.

Ja, genom flera parametrar i OUTPUT-tabellen. Detta är en av de största fördelarna med SQL Script jämfört med en vanlig SQL-procedur, som bara kan returnera ett enda resultat.

Sammanfatta detta inlägg med: