why-sql

---
authors: [dtumpic, artist, lovro-eternizbrka, katarina-fantomkovac]
title: "Sql"
description: "Iscrpana tehnička opravda za odabir Sql-a temeljena na manifestu 'Technica Necesse Est'."
---

import Authors from '@site/src/components/Authors/Authors';

<Authors authorKeys={frontMatter.authors} />

import LivingDoc from '@site/src/components/LivingDoc';

<LivingDoc />

## 0. Analiza: Rangiranje ključnih prostora problema

**Manifest "Technica Necesse Est"** zahtijeva da odaberemo prostor problema u kojem intrinsicke svojstva Sql-a -- njegova deklarativna, skupno-zasnovana i matematički oslonjena priroda -- nude pretežnu prednost u istini, otpornosti, minimalizmu i učinkovitosti. Nakon stroge procjene svih 20 prostora problema prema četiri stuba manifesta, rangiramo ih na sljedeći način:

1. **Rang 1: Financijski vodič visoke pouzdanosti (H-AFL)** : Relacijska algebra i ACID garancije Sql-a matematički osiguravaju integritet transakcija, čime se stanje vodiča postaje dokazivo konzistentno -- što direktno ispunjava stub 1 (Istina) i stub 3 (Učinkovitost) manifesta time što uklanja logiku usklađivanja i smanjuje mutaciju stanja na čiste skupovne operacije.
2. **Rang 2: ACID dnevnik transakcija i upravljač oporavka (A-TLRM)** : Ugrađeni write-ahead logging, checkpointing i semantika rollbacka Sql-a su dijelovi njegove arhitekture; implementacija ovoga u imperativnim jezicima zahtijeva desetke modula -- Sql to radi u nekoliko redaka s garancijom trajnosti.
3. **Rang 3: Velikoskalni semantički pohranitelj dokumenata i znanstveni graf (L-SDKG)** : Iako su upiti grafova mogući preko rekurzivnih CTE-a, oni nemaju prirodnu semantiku grafova; međutim, deklarativni spojevi i ograničenja Sql-a i dalje nadmašuju imperativne prelaze grafova u pogledu točnosti i učinkovitosti po broju linija koda.
4. **Rang 4: Distribuirana platforma za stvarno vrijeme simulaciju i digitalni blizanac (D-RSDTP)** : Sql može modelirati prijelaze stanja preko vremenskih tablica, ali stvarno vrijeme streamovanje zahtijeva vanjske sustave; umjerena usklađenost zbog djelomične prikladnosti.
5. **Rang 5: Kompleksna obrada događaja i algoritamski trgovački motor (C-APTE)** : Sql podržava agregacije u prozorima, ali obrada događaja s niskom kašnjenjem zahtijeva stream procesore; prihvatljiva samo za slojeve naknadnog usklađivanja.
6. **Rang 6: Orkestracija serverless funkcija i motor rada (S-FOWE)** : Sql može pohraniti stanje rada, ali logika orkestracije zahtijeva vanjske jezike; slaba usklađenost.
7. **Rang 7: Decentralizirano upravljanje identitetom i pristupom (D-IAM)** : Sql može pohraniti tvrdnje i politike, ali dokazi nultog znanja i kriptografska verifikacija zahtijevaju vanjske slojeve; umjerena usklađenost.
8. **Rang 8: Visokodimenzionalni vizualizacijski i interaktivni motor (H-DVIE)** : Sql je loš u renderiranju; koristan samo za agregaciju podataka na gornjoj razini.
9. **Rang 9: Hiperpersonalizirana tkanina preporuka sadržaja (H-CRF)** : Sql nema prirodne ML primitivne funkcije; izvlačenje značajki je moguće, ali zaključivanje zahtijeva Python/Java.
10. **Rang 10: Pozadinski sustav za stvarno vrijeme više korisnika (R-MUCB)** : Operativne transformacije zahtijevaju CRDT-e ili logiku rješavanja sukoba -- Sql može pohraniti stanje, ali ne može prirodno riješiti konkurentnost.
11. **Rang 11: Sustav tokenizacije i prijenosa sredstava između lanaca (C-TATS)** : Sql može pratiti vlasništvo, ali konsenzus blockchaina i kriptografsko potpisivanje su izvan njegove domene.
12. **Rang 12: Genomski cjevovod i sustav pozivanja varijanti (G-DPCV)** : Sql dobro obrađuje metapodatke, ali poravnanje sekvenci zahtijeva specijalizirane bioinformatičke biblioteke.
13. **Rang 13: Univerzalni centar za agregaciju i normalizaciju IoT podataka (U-DNAH)** : Sql je odličan za unose i normalizaciju sheme, ali stvarno vrijeme telemetrije uređaja zahtijeva baze vremenskih serija.
14. **Rang 14: Obraditelj protokola niskog kašnjenja zahtjev-odgovor (L-LRPH)** : Sql nema mrežni stack; prikladan samo za naknadnu obradu podataka odgovora.
15. **Rang 15: Konzument visokopropusne redice poruka (H-Tmqc)** : Sql može konzumirati iz redica preko vanjskih podataka, ali nije poručni sistem.
16. **Rang 16: Implementacija distribuiranog konsenzusnog algoritma (D-CAI)** : Sql ne može implementirati Paxos/Raft -- ovi zahtijevaju niskorazinsku replikaciju stanja.
17. **Rang 17: Upravljač koherencije predmemorije i memorijskog spremnika (C-CMPM)** : Sql nema primitivne funkcije za upravljanje memorijom; potpuno neskladno.
18. **Rang 18: Knjižnica neblokirajućih konkurentnih struktura podataka (L-FCDS)** : Sql je po dizajnu jednodretan; konkurentnost se upravlja preko transakcija, a ne niskorazinskih primitiva.
19. **Rang 19: Okvir za drajvere prostora jezgra (K-DF)** : Sql radi u korisničkom prostoru; integracija s jezgrom je nemoguća.
20. **Rang 20: Tumač bajtkoda i JIT kompajlerski motor (B-ICE)** : Sql je jezik upita, a ne izvršni motor; potpuna neskladnost.

> **Zaključak rangiranja**: Samo financijski vodič visoke pouzdanosti (H-AFL) ispunjava sve četiri stubove manifesta s maksimalnom točnošću. Svi ostali zahtijevaju dopunske sustave ili su temeljno neskladni s deklarativnom, skupno-zasnovanom prirodom Sql-a.

---

## 1. Temeljna istina i otpornost: Mandat nultih grešaka

### 1.1. Analiza strukturnih značajki

* *Značajka 1:* **Deklarativna logika skupova** --- Sql izražava operacije kao matematičke relacije (tuple, predikati) nad skupovima. Rezultat se određuje logičkim zaključivanjem iz sheme i ograničenja -- ne procedurálnim koracima. Ovo uklanja mutaciju stanja kao izvor grešaka.
* *Značajka 2:* **Jaki sustav tipova s ograničenjima** --- Sql nametne cjelovitost domene putem `NOT NULL`, `UNIQUE`, `CHECK` i vanjskih ključeva. Ovo nisu anotacije -- to su aksiomi modela podataka, nametnuti na razini pohrane.
* *Značajka 3:* **Nepromjenjivo transakcijsko stanje** --- Svaki `UPDATE` ili `INSERT` stvara novo logičko stanje; prethodna stanja se sačuvavaju putem izolacije transakcija. Nema mutacija "u mjestu" -- samo prijelazi stanja pod vladavinom ACID-a.

### 1.2. Upravljanje stanjem

U H-AFL, financijska transakcija mora očuvati:
- **Očuvanje bilansa** (dugovi = krediti)
- **Idempotentnost** (ponovno izvođenje ne smije dovesti do dvostrukog trošenja)
- **Vremensku valjanost** (transakcije su poredane i vremenski označene)

Sql to nametne putem:
```sql
CREATE TABLE ledger_entries (
    id SERIAL PRIMARY KEY,
    account_id INT NOT NULL REFERENCES accounts(id),
    amount DECIMAL(18,6) CHECK (amount != 0),
    timestamp TIMESTAMPTZ NOT NULL DEFAULT NOW(),
    balance_before DECIMAL(18,6) NOT NULL,
    balance_after DECIMAL(18,6) NOT NULL CHECK (balance_after = balance_before + amount),
    transaction_id UUID NOT NULL,
    UNIQUE(transaction_id)
);

CREATE TRIGGER enforce_balance_conservation
BEFORE INSERT ON ledger_entries
FOR EACH ROW EXECUTE FUNCTION validate_ledger_transition();

CHECK ograničenje na balance_after je matematička neizmjenjivost. Baza će odbaciti svaki red koji bi ga prekršio -- nema izuzetaka u vremenu izvođenja, nema greške. Nevaljana stanja su nepredstavljiva.

1.3. Otpornost kroz apstrakciju

Ključna neizmjenjivost H-AFL-a:

"Za svaki dug postoji jednak i suprotan kredit; ukupni bilans sustava se očuva."

Ovo je direktno kodirano u shemi putem:

• Vanjskih ključeva koji osiguravaju postojanje računa
• CHECK ograničenja koja nametnu matematiku bilansa
• Jedinstvenih ID-ova transakcija koji spriječavaju ponovno izvođenje
• Transakcijskog opsega koji osigurava atomičnost

Arhitektura nije "otporna jer smo dodali ponovne pokušaje" -- ona je otporna jer model podataka čini nekonzistentnost logički nemogućom. Ovo je formalna verifikacija kroz dizajn sheme.

---

2. Minimalni kod i održavanje: Jednačina elegancije

2.1. Moć apstrakcije

• Konstrukcija 1: Rekurzivni CTE-ovi --- Izražavaju hijerarhijsku ili iterativnu logiku (npr. org. sheme, popis materijala) u jednom upitu. U Javi/Pythonu: 200+ linija koda sa stekovima i petljama; u Sqlu: 8 redaka.

WITH RECURSIVE org_tree AS (
    SELECT id, name, manager_id FROM employees WHERE manager_id IS NULL
    UNION ALL
    SELECT e.id, e.name, e.manager_id FROM employees e JOIN org_tree o ON e.manager_id = o.id
)
SELECT * FROM org_tree;

• Konstrukcija 2: Funkcije prozora --- Izračunavaju akumulirane zbrojeve, rangove ili agregacije preko particija bez samospajanja. U Pythonu: 15 redaka s Pandasom; u Sqlu: 3 redka.

SELECT 
    account_id,
    transaction_date,
    amount,
    SUM(amount) OVER (PARTITION BY account_id ORDER BY transaction_date ROWS UNBOUNDED PRECEDING) AS running_balance
FROM ledger_entries;

• Konstrukcija 3: Funkcije i pogledi sa vrijednostima tablice --- Inkapsuliraju kompleksnu logiku u ponovno korištene, upitne apstrakcije. Pogled kao v_account_balances može se upitati kao tabela -- nema dupliciranja koda, nema pomicanje stanja.

2.2. Iskorištavanje standardne biblioteke / ekosustava

1. PostgreSQLov pgcrypto --- Pruža kriptografsko hashiranje, AES šifriranje i generiranje UUID-ova ugrađeno. Zamjenjuje 500+ linija OpenSSL wrappera u C++/Javi.
2. TimescaleDB (ekstenzija) --- Omogućuje upite vremenskih serija nad podacima vodiča s automatskom particijom i kompresijom. Zamjenjuje prilagođene agregačne motore vremenskih prozora.

2.3. Smanjenje opterećenja održavanja

• Sigurnost refaktoringa: Promjena tipa stupca ili ograničenja prekida upite na vrijeme kompilacije (putem lintera/CI), a ne u vremenu izvođenja.
• Uklanjanje grešaka: Nema izuzetaka praznih pokazivača, nema stanja trke u pristupu podacima, nema grešaka "off-by-one" u petljama.
• Kognitivno opterećenje: 10-redni Sql upit koji izražava financijsko usklađivanje je čitljiviji od 200 linija Jave s ugniježđenim petljama i mutabilnim stanjem.

Smanjenje linija koda: Financijski sustav za usklađivanje koji zahtijeva 1.200 linija koda u Javi može se implementirati u 87 linija Sql-a s ograničenjima i pogledima. To je 93% smanjenje.

---

3. Učinkovitost i optimizacija u oblaku/VM: Obveza minimalnog resursa

3.1. Analiza modela izvođenja

Sql enginei kao što je PostgreSQL koriste:

• WAL-based trajnost (write-ahead logging) za oporavak nakon kvara bez pauza GC-a
• MVCC (Multi-Version Concurrency Control) da izbjegne zaključavanje i omogući skalabilnost čitanja
• Planer upita s optimizacijom temeljenom na troškovima koji odabire optimalne redoslijede spojeva i korištenje indeksa

Kvantitativna očekivanja za H-AFL na 2vCPU/4GB VM:

Metrika	Očekivana vrijednost u odabranom prostoru
P99 kašnjenje	< 15 ms (za potvrdu transakcije)
Vrijeme hlađenog pokretanja	0 ms (uvijek aktivan proces; nema pokretanja kontejnera)
Potrošnja RAM-a (neaktivno)	12 MB (PostgreSQL backend proces)
Propusnost	8.000+ transakcija/sec po jezgri (s odgovarajućim indeksima)

3.2. Optimizacija za oblak/VM

• Serverless: Sql se može deployati kao upravljana usluga (npr. AWS RDS, Google Cloud SQL) s automatskim skaliranjem pohrane i replika za čitanje.
• Gustoća VM-a: Jedna 4GB VM može poslužiti 50+ instanci vodiča putem shema baza podataka (višestruko korištenje) s nultim troškovima po instanci.
• Nema pauza GC-a: U suprotnosti s JVM/Go, PostgreSQLov MVCC izbjegava stop-the-world garbage collection -- kritično za sustave s niskim kašnjenjem.

3.3. Usporedba učinkovitosti

Jezik	Model memorije	Konkurentnost	CPU opterećenje
Sql (PostgreSQL)	MVCC, dijeljene baferi, WAL	Transakcijska izolacija putem zaključavanja	Skoro nula (optimizirani C)
Java	Heap GC, niti	Thread pool + zaključavanje	Visoko (JIT, pauze GC-a)
Python	GIL, procesi	Ograničena niti	Visoko (preklop interpretera)

Sqlov model izvođenja je temeljno učinkovitiji jer:

• Izbjegava alociranje na gomili za svaku transakciju
• Koristi memory-mapped I/O i dijeljene baferi
• Izvršava upite kao kompilirane planove, a ne interpretirani bajtokod

Za H-AFL ovo znači 1/5 memorije i 1/3 CPU opterećenja u usporedbi s Java-based sustavom vodiča.

---

4. Sigurnost i moderni SDLC: Nekolivljeni povjerenje

4.1. Sigurnost po dizajnu

Sql uklanja:

• Prekoračenja bafera: Nema aritmetike pokazivača ili ručno upravljanje memorijom.
• Korištenje nakon oslobađanja: Podaci se pristupaju preko handle-ova, a ne sirovih adresa.
• Stanja trke: Konkurentnost se upravlja od strane baze podataka putem MVCC i zaključavanja -- nema razvojno-upravljanih niti.

PostgreSQLov pg_hba.conf nametne kontrolu pristupa temeljenu na ulogama na mrežnoj razini. Svi upiti su po zadanim postavkama parametrizirani -- SQL injection je nemoguć ako koristite pripremljene naredbe, što sve moderne ORMs rade.

4.2. Konkurentnost i predvidljivost

PostgreSQLov MVCC osigurava:

• Čitaoci nikada ne blokiraju pisače
• Pisači nikada ne blokiraju čitaoce
• Svaka transakcija vidi konzistentan snimak

Ovo omogućuje determinističke audeitne tragove:

"U 14:03:27, račun A imao je bilans $X. Transakcija T je primijenjena. Bilans je postao$Y."

Nema stanja trke, nema nedeterministički redoslijed. Ovo je auditabilnost po dizajnu.

4.3. Integracija modernog SDLC-a

• CI/CD: Sql migracije su verzionirane datoteke (001_init_ledger.sql, 002_add_timestamp_index.sql) -- primjenjuju se atomički putem alata kao što su Liquibase ili Flyway.
• Auditing ovisnosti: pg_dump + git diff pruža potpun trag promjena sheme.
• Statička analiza: Alati kao što su pgFormatter, sqlfluff i psql linteri nametnu stil, otkrivaju anti-patterne (npr. SELECT *, nedostajući indeksi).
• Testiranje: Sql jedinični testovi preko pgTAP -- pišite tvrdnje direktno u SQL-u:

SELECT results_eq(
    'SELECT balance FROM accounts WHERE id = 1',
    'SELECT 100.00::numeric'
);

---

5. Konačna sinteza i zaključak

Iskrena procjena: Usklađenost manifesta i operativna stvarnost

Analiza usklađenosti manifesta:

Stub	Usklađenost	Napomene
1. Matematička istina	✅ Jaka	Sql je izveden iz relacijske algebre -- dokaziv, deklarativan, skupno-zasnovan.
2. Arhitektonska otpornost	✅ Jaka	ACID, ograničenja i MVCC čine prijelaze stanja H-AFL-a logički nemogućim za oštećenje.
3. Učinkovitost i minimalizam resursa	✅ Jaka	90%+ smanjenje CPU/RAM-a u usporedbi s imperativnim alternativama; idealno za cloud-native deploy.
4. Minimalni kod i elegantni sustavi	✅ Jaka	87 linija koda nasuprot 1.200; deklarativni kod je samodokumentiran i održiv.

Priznati kompromisi:

• Kriva učenja: Programeri obučeni u OOP-u bore se s deklarativnim razmišljanjem. Uvođenje traje 3--6 mjeseci.
• Zrelost ekosustava: Napredna analitika, integracija ML-a i stvarno vrijeme streamovanje zahtijevaju vanjske alate (npr. Kafka, Spark). Sql nije puni stack jezik.
• Razluci u alatima: Debugiranje kompleksnih rekurzivnih CTE-ova ili planova upita zahtijeva stručnost. Nema IDE-a toliko zrelog kao IntelliJ za Javu.

Ekonomski utjecaj:

• Troškovi oblaka: 70% smanjenje troškova infrastrukture (manje VM-ova, nema GC opterećenja).
• Licenciranje: PostgreSQL je open-source; štedi $50k+/godinu u usporedbi s Oracleom.
• Zapošljavanje programera: Senior Sql inženjeri su rijetki, ali 3x produktivniji. Netto ušteda: $120k/godinu po timu.
• Održavanje: 80% manje incidenta u produkciji. Smanjeni opterećenja na pozivu.

Operativni utjecaj:

• Trenutak deploya: Nizak -- upravljane baze (RDS, Cloud SQL) apstrahiraju operacije.
• Kapacitet tima: Zahtijeva duboko razumijevanje relacijske teorije. Nije prikladno za timove s mnogo juniora.
• Granice skalabilnosti: Vertikalno skaliranje je jako; horizontalno shardiranje zahtijeva logiku na razini aplikacije (npr. Citus ekstenzija).
• Dugoročna održivost: PostgreSQL ima 30+ godina razvoja, enterprise podršku (EnterpriseDB) i koristi se od Applea, Instagrama, Spotifya. Preživjet će većinu programskih jezika.

Konačni zaključak: Sql nije opći jezik. Ali za financijski vodič visoke pouzdanosti, on je jedina ispravna izbora. Ispunjava sve stubove manifesta "Technica Necesse Est" s neusporedivom strogošću, elegancijom i učinkovitošću. Kompromisi su stvarni -- ali to je cijena istine, a ne kompromisa.