– ORM er som å strikke med skiftenøkler!

Det er mange fordeler ved å skrive SQL-spørringene selv fremfor å bruke en ORM, mener Sindre Kvålsgard, CTO i Yne.

Sindre Kvålsgard, CTO i Yne.
Publisert

✍ leserinnlegg

Dette er et leserinnlegg fra en ekstern skribent, som betyr at innholdet ikke nødvendigvis speiler kode24s meninger. Vil du også bidra? Send oss en epost på [email protected], eller les mer her!

Først, hva er en ORM?

En ORM (Object-Relational Mapper) er et verktøy eller bibliotek som gjør det mulig å jobbe med databaser ved å representere tabeller som objekter i et programmeringsspråk, slik at man kan lese og skrive data uten å bruke rå SQL-spørringer. (Eksempel: Entity Framework for .NET)

Det finnes noen positive sider ved å bruke en ORM, men de skal vi ikke diskutere her. For balansen nevner jeg enklere kode og redusert risiko for sikkerhetsfeil. Det vi derimot skal snakke om her, er fordelene ved å ikke bruke en ORM!

Setter begrensninger

En SQL-server skalerer hovedsakelig vertikalt, som betyr at du når et tak på hvor mye RAM, CPU og I/O som er tilgjengelig på instansen. Altså, du kan ikke kubernetifisere deg ut av problemet.

Du kan ikke kubernetifisere deg ut av problemet.

Så hva gjør man da når databasen begynner å bli flaskehalsen på systemet? Du tuner databasen og spørringene. Dette er ikke alltid like enkelt om du har en ORM mellom databasen og backenden, som skal blande seg eller sette begrensninger for dette. Flere kokker, mer søl!

Det er veldig mye finjustering av en SQL-database og spørringer man kan gjøre for å effektivisere dataflyten. 

Med en ORM blir det litt som å strikke med skiftenøkler – det går an, men det blir ikke optimalt.

Trenger ikke ORM

Er du redd for SQL-injeksjoner? Bra, det bør du være! Men det kan enkelt løses med parametere, og det trenger du ikke en ORM til.

I mange tilfeller kommer ytelse aldri til å bli et problem, og om det dukker opp kan man jo bare øke maskinvaren på databaseinstansen, mot en kostnadsøkning selvfølgelig.

Så om ytelsesproblematikk ikke er situasjonen hos deg, kan du bare herje tulling! Skriv SQL-syntaks som får deg utestengt fra Azure, eller aksepter alt av boilerplate ORM-er fra Copilot til du har sprengt token-lengden.

Så er det bare å lene seg tilbake og se systemet kjøre sømløst med energieffektiviteten til en bitcoin-transaksjon.

Powered by Labrador CMS