# Designet et funksjonsbasert datalag i PostgreSQL — 1 275 lagrede funksjoner fordelt på 34 skjemaer — slik at hver lesing og skriving går gjennom en funksjon databasen kan gi tilgang til, i stedet for gjennom en tabell. 2025 **Situasjon.** Forretningslogikk har en tendens til å lekke. Litt havner i API‑et, litt i noe SQL en handler kjører direkte, og snart er den samme regelen skrevet på to eller tre litt ulike måter, og det finnes ikke ett sted man kan peke på og si «dette er hva systemet gjør med dataene sine». Det er slik feil og sikkerhetshull kommer inn. **Oppgave.** Målet var ett sted for alt sammen: hver lesing og skriving skulle gå gjennom databasen, API‑et skulle være en tynn adapter som ikke kjenner forretningsreglene, og det hele skulle kunne låses stramt ned. **Handling.** Datalaget er bygget med funksjonene først. Skjemaet er delt opp etter domene — identity, organization, review, message, notification og 29 til, 34 i alt — og hver operasjon appen kan utføre, er én av 1 275 PostgreSQL‑funksjoner den kaller; det finnes ingen direkte tabelltilgang fra Go i det hele tatt. Deretter håndhever databasen det. Rollen API‑et logger inn som, mariner, har EXECUTE på appfunksjonene og USAGE på skjemaene og ingenting annet — ingen SELECT, ingen INSERT, ingen mulighet til å røre en tabell direkte — noe som blir omtrent 4 000 eksplisitte tildelinger i stedet for én generell. Funksjonene kjører som SECURITY DEFINER, eid av en egen function_owner‑rolle uten innlogging og med fast search_path, og superbrukerkontoen er forbeholdt migreringer og cron, godt unna den kjørende appen. **Resultat.** Logikken bor på ett sted som faktisk kan revideres, API‑et forblir tynt og kjedelig på den gode måten, og tilgangsgrensen håndheves av Postgres selv i stedet for av at alle husker reglene. Skulle API‑et på en eller annen måte bli kompromittert, kunne det likevel ikke gjøre noe funksjonene ikke tillater. Med 1 275 funksjoner koster disiplinen noe reelt — et nytt felt er en migrering og en funksjonsendring, ikke en linje i en spørring — og den friksjonen er prisen for at grensen holder. --- - Rolle: Databaseingeniør - Kategorier: [Plattformarkitektur](https://data.engineer.company/nb/categories/platform-architecture/), [Backend‑utvikling](https://data.engineer.company/nb/categories/backend/), [Databaser](https://data.engineer.company/nb/categories/databases/), [PostgreSQL](https://data.engineer.company/nb/categories/postgresql/), [SQL](https://data.engineer.company/nb/categories/sql/), [Datastyring](https://data.engineer.company/nb/categories/data-governance/), [Sikkerhet](https://data.engineer.company/nb/categories/security/) - Tjenester: [Plattform- og løsningsarkitektur](https://data.engineer.company/nb/services/platform-architecture/), [Backend- og API‑utvikling](https://data.engineer.company/nb/services/backend-development/), [Databasedesign og datamodellering](https://data.engineer.company/nb/services/database-design/), [Datastyring og datakvalitet](https://data.engineer.company/nb/services/data-governance/)