SQL kan användas för att skapa re­la­tions­da­ta­ba­ser och utföra en rad olika ope­ra­tio­ner på be­fint­li­ga databaser, inklusive da­ta­kon­sul­ta­tio­ner. Språket ingår i stan­dar­dre­per­to­a­ren för web­b­ut­veck­la­re, da­taa­na­ly­ti­ker och forskare. Men jämfört med andra pro­gram­me­rings­språk är SQL speciellt. Vi förklarar språkets egen­ska­per.

Vad är SQL egent­li­gen?

SQL är en för­kort­ning av Structu­red Query Language (struk­tu­re­rat frå­ge­språk). Det kan användas för att göra sökningar i databaser som in­ne­hål­ler struk­tu­re­ra­de eller re­la­tio­nel­la data. Språket baseras påre­la­tio­nell algebra, en ma­te­ma­tisk teori för att struk­tu­re­ra data och beräkna re­sul­ta­ten av sökningar. Många av de speciella egen­ska­per­na hos SQL som pro­gram­me­rings­språk härrör från denna ma­te­ma­tis­ka grund. SQL ut­veck­la­des i mitten av 1970-talet och anses idag vara det stan­dar­di­se­ra­de pro­gram­me­rings­språ­ket för da­ta­basap­pli­ka­tio­ner.

En viktig detalj om SQL är att det är ett rent frå­ge­språk eller pro­gram­me­rings­språk, inte ett om­fat­tan­de da­ta­bashan­te­rings­sy­stem (DBMS). Några populära DBMS som im­ple­men­te­rar SQL är MySQL, Oracle SQL och SQLite. Dessa DBMS använder dock mestadels dialekter av SQL, som kan ha yt­ter­li­ga­re och/eller olika kommandon.

SQL som ett do­män­spe­ci­fikt och de­kla­ra­tivt språk

Jämfört med de flesta eta­ble­ra­de pro­gram­me­rings­språk är SQL speciellt eftersom det är ett do­män­spe­ci­fikt språk (DSL). Till skillnad från allmänna pro­gram­me­rings­språk (GPL), som är lämpliga för an­vänd­ning i många olika ap­pli­ka­tio­ner, kan SQL endast användas för en sak, nämligen databaser.

SQL är också ett de­kla­ra­tivt pro­gram­me­rings­språk. Det innebär att pro­gram­me­ra­ren anger ett önskat resultat som ett kommando och systemet ser till att detta resultat uppnås. Detta står i kontrast till imperativ pro­gram­me­ring, där de enskilda stegen för att uppnå målen de­fi­nie­ras explicit i koden.

Vad används SQL till?

SQL fungerar som ett gräns­snitt för in­ter­ak­tion med re­la­tions­da­ta­bashan­te­rings­sy­stem (RDBMS). En re­la­tions­da­ta­bas kan ses som en tabell där varje rad har en för­ut­be­stämd upp­sätt­ning attribut som fylls med värden. SQL-koden kan antingen matas in av människor via ett text­ba­se­rat gräns­snitt eller in­te­gre­ras i API-åtkomst.

Fördelar och nackdelar med SQL

Fördelar med SQL

Den största fördelen med SQL ligger i teknikens höga profil och utbredda an­vänd­ning. Sedan dess tillkomst på 1970-talet har SQL varit bransch­stan­dard för da­ta­basap­pli­ka­tio­ner. Detta gör det relativt enkelt att hitta erfarna SQL-pro­gram­me­ra­re, liksom gräns­snitt till andra vanliga tekniker och språk.

Dessutom har SQL blivit bransch­stan­dard av en anledning. Språket bygger på en robust ma­te­ma­tisk grund som möjliggör optimal da­ta­lag­ring. Re­la­tio­nel­la databaser kräver dock en gedigen för­stå­el­se för tekniken och teorin, samt skick­lig­het och planering i mo­del­le­ring. Men ett väl utformat da­ta­bas­sche­ma gör det möjligt att få nya insikter från data genom lämpliga frågor.

Nackdelar med SQL

En nackdel med SQL och re­la­tions­da­ta­ba­ser i allmänhet är teknikens höga kom­plex­i­tet. SQL består av hund­ra­tals kommandon och klausuler, vilket utgör en stor utmaning för nybörjare. Många av dessa är im­ple­men­te­rings­spe­ci­fi­ka, vilket gör det ännu mer utmanande.

Dessutom kräver struk­tu­ren i en re­la­tions­da­ta­bas ett antal an­ta­gan­den om de data som ska lagras. Dessa tjänar till att sä­ker­stäl­la kva­li­te­ten på de lagrade upp­gif­ter­na, men medför också ett antal be­gräns­ning­ar som kan orsaka per­ma­nen­ta problem om schemat är dåligt utformat. Ändringar av schemat under drift kan utgöra en allvarlig utmaning. Utöver denna brist på flex­i­bi­li­tet är det van­ligt­vis mycket svårt att dis­tri­bu­e­ra en SQL-databas geo­gra­fiskt. Att optimera da­ta­ba­sens prestanda genom de­cent­ra­li­se­ring är därför allt annat än enkelt.

En sista nackdel med SQL är dess in­kom­pa­ti­bi­li­tet med den allmänt använda ob­jek­t­o­ri­en­te­ra­de pro­gram­me­ring­en, som blir allt mer relevant. I ob­jek­t­o­ri­en­te­rad pro­gram­me­ring kapslas data och “beteende” (metoder) in i objekt. Data och metoder ärvs genom klas­struk­tur. Den re­la­tio­nel­la metoden skiljer sig fun­da­men­talt från detta, eftersom data kan fördelas över flera tabeller. Dessutom är det omöjligt att modellera ett objekts beteende. Av denna anledning kan objekt inte överföras 1:1 till re­la­tio­nel­la da­ta­bas­struk­tu­rer.

Al­ter­na­tiv till SQL

Eftersom SQL uppfanns i början av den digitala re­vo­lu­tio­nen har språket inte förlorat sin relevans. Sedan dess har dock vissa al­ter­na­ti­va scheman dykt upp som kan vara mer lämpliga för vissa tillämp­ning­ar.

Ob­jekt­re­la­te­ra­de da­ta­bashan­te­rings­sy­stem

Ob­jekt­re­la­te­ra­de da­ta­bashan­te­rings­sy­stem (ORDBMS) som Post­greSQL använder SQL som frå­ge­språk, men stöder också kärn­kon­cep­ten i ob­jek­t­o­ri­en­te­rad pro­gram­me­ring. Ob­jekt­hi­e­rar­ki­er, arv och ob­jekt­be­te­en­de kan användas utan ob­jekt­re­la­te­rad mappning (ORM). Särskilt an­vän­dar­de­fi­ni­e­ra­de och sam­man­sat­ta datatyper minskar kom­plex­i­te­ten i scheman och frågor.

NoSQL

SQL-baserade DBMS är främst avsedda för lagring av struk­tu­re­ra­de data, men alla data följer inte ett fast schema. Det är här NoSQL-databaser kommer in i bilden. Termen NoSQL avser en familj av icke-re­la­tio­nel­la DBMS. Istället för att modellera data som fält i en tabell används olika andra metoder.

En populär metod är do­ku­ment­ba­se­rad lagring av data. Detta fungerar genom att data lagras i enskilda dokument istället för i en tabell. En fördel med den do­ku­ment­ba­se­ra­de metoden är att data kan vara själv­skri­van­de. Detta innebär att da­ta­struk­tu­ren bestäms av det enskilda do­ku­men­tet, inte av databasen, vilket innebär att da­ta­pos­ter kan följa olika struk­tu­rer.

NoSQL-lösningar är van­ligt­vis mindre komplexa och erbjuder fördelar när det gäller skal­bar­het och pre­stan­da­op­ti­me­ring. Dessutom är det oftast enklare att ändra schemat under drift eller att lagra data på ett flexibelt sätt. Å andra sidan kan det finnas färre garantier när det gäller da­ta­kva­li­te­ten.

Gå till huvudmeny