Kas yra saugomos procedūros ir kada jas turėtumėte naudoti?

Question

Accepted Answer

**Saugota procedūra** yra SQL sakinių ir procedūrinio kodo rinkinys, išsaugojtas duomenų bazėje ir vykdomas pagal pavadinimą. Ji vykdo logiką *duomenų bazės viduje*, o ne programos kode. Jos turi tikrų privalumų, tačiau ir reikšmingų kompromisų, todėl sprendimas, kada jas naudoti, yra tiesaus architektūrinio pasirinkimo klausimas.

## Saugota procedūra

```sql
-- define a procedure that encapsulates logic in the database
CREATE PROCEDURE transfer_funds(from_id INT, to_id INT, amount DECIMAL)
LANGUAGE plpgsql AS $$
BEGIN
  UPDATE accounts SET balance = balance - amount WHERE id = from_id;
  UPDATE accounts SET balance = balance + amount WHERE id = to_id;
  -- can include logic: conditionals, loops, error handling, transactions
END;
$$;

CALL transfer_funds(1, 2, 100);   -- execute by name
```

Saugota procedūra sujungia SQL ir procedūrinį kodą (kintamuosius, sąlyginius operatorius, ciklus, klaidų tvarkymo logiką) į pavadintą, pakartotinai naudojamą duomenų bazės rutininą. Funkcijos yra panašios, bet grąžina reikšmę.

## Potencialūs privalumai

```text
✓ Performance — runs IN the database (no round-trips for multi-step logic); precompiled
✓ Reduced network traffic — one call vs many queries from the app
✓ Reusability — shared logic callable from multiple applications/clients
✓ Security — grant EXECUTE on a procedure without granting table access; reduces
  injection surface (parameterized)
✓ Consistency — centralize critical logic so all clients use the same implementation
```

## Reikšmingi kompromisai (kodėl šiandien daugelis jų vengia)

```text
✗ Business logic in the DATABASE → harder to version-control, test, and maintain
  (logic split between app code and the database)
✗ Database-specific (PL/pgSQL vs T-SQL vs PL/SQL) → less portable, vendor lock-in
✗ Harder to debug than application code; weaker tooling
✗ Scaling — the database is often the hardest tier to scale; pushing logic there
  can increase its load
✗ Modern apps often prefer logic in the application layer (testable, portable, versioned)
```

## Kada jas naudoti

```text
✓ Performance-critical data-intensive operations (heavy multi-step DB logic, batch jobs)
✓ Logic that MUST be enforced at the DB level across multiple clients
✓ Reducing round-trips for operations involving many queries
✗ AVOID putting general business logic in procedures by default — modern practice
  usually favors the application layer (better testing, versioning, portability)
```

## Kodėl tai svarbu

Supratimas apie saugotas procedūras — įskaitant jų kompromisus — yra vertingas žinios turtas, nes jos reiškia tikrą architektūrinį pasirinkimą su tikrais privalumais ir tikrais trūkumais. Žinojimas, *kada* jas naudoti (ir kada ne), atspindi brandų sprendimų priėmimą.

Saugotos procedūros gali suteikti **našumo privalumų** (kelių žingsnių logikos vykdymas duomenų bazės viduje išvengia tinklo maršrutizavimo), sumažina tinklo srauto kiekį, suteikia pakartotinio naudojimo galimybę skirtingiems klientams, saugumą (suteikiant vykdymo privilegijas be lentelių prieigos), o taip pat centralizuotą nuoseklumą — todėl jos tinka našumo atžvilgiu kritiniams duomenimis intensyviems operacijoms, paketinei apdorojimui ir logiikai, kuri turi būti nuodugniai įgyvendinta duomenų bazės lygiu, remiantis keliais programomis.

Tačiau **reikšmingų kompromisų** supratimas yra vienodai svarbus ir atspindi šiuolaikinę praktiką: verslo logikos dėjimas į duomenų bazę ją sunkiau versijavimui, testavimui ir priežiūrai (logika yra padalinta tarp programos ir duomenų bazės), jūs esate surišti su konkrečia duomenų bazės procedūrinio kodo kalba (PL/pgSQL, T-SQL, PL/SQL — sumažina portabilumą), ji sunkiau derinasi, ir prideda apkrovą duomenų bazės sluoksniui (dažnai sunkiausią išplėsti).

Dėl šių priežasčių, **šiuolaikinė programų kūrimo praktika dažnai pirmenybę teikia verslo logikos laikymui programos sluoksnyje** (testuojamam, perkeliamam, versijavamam) nei saugotuose procedūrose.

Pagrindinė nuosvyra yra **sprendimas, kada jas naudoti** — tinka konkretiems našumo kritiniams ar duomenų bazės lygmens įgyvendinimo poreikiams, bet paprastai vengiamos kaip numatytoji verslo logikos priemonė.

Badant atsižvelgiant į tai, kad saugotos procedūros yra dažnos daugelyje sistemų (ypač šiuolaikinėse/senojo tipo), ir atsižvelgiant į tai, kad supratimas apie jų privalumų ir kompromisų (ir šiuolaikinę link programos sluoksnio nukreiptą orientaciją) yra tai, kas leidžia priimti tvirtus architektūrinius sprendimus, saugotų procedūrų supratimas yra vertingas aukšto lygio žinios, kurias panaudojus gali įrodyti gebėjimą svarstyti duomenų bazės ir programos sluoksnio logikę — tai yra reikšminga dizaino aplinkybė ir tema, atspindinti architektūrinį brandumą.