{"id":30,"date":"2023-06-03T09:50:00","date_gmt":"2023-06-03T07:50:00","guid":{"rendered":"https:\/\/djax.se\/blog\/?p=30"},"modified":"2023-06-03T09:50:00","modified_gmt":"2023-06-03T07:50:00","slug":"sql-som-applikations-sprak","status":"publish","type":"post","link":"https:\/\/djax.se\/?p=30","title":{"rendered":"SQL som applikations spr\u00e5k"},"content":{"rendered":"\n

Mjukvara \u00e4r skriven i programmeringsspr\u00e5k. Dessa spr\u00e5k delas upp p\u00e5 olika s\u00e4tt som h\u00f6g- och l\u00e5gniv\u00e5 eller i generationer som ”fj\u00e4rde generationens spr\u00e5k”<\/a>. SQL \u00e4r ett s\u00e5dant ”fj\u00e4rde generationens” spr\u00e5k. Tanken var att kunna beskriva vad som \u00f6nskas fr\u00e5n datorn ist\u00e4llet f\u00f6r p\u00e5 ett exakt vis koda hur <\/strong>informationen skall samlas ihop p\u00e5. G\u00e4rna att personer utan programmeringsbakgrund skulle kunna deklarera <\/strong>egna fr\u00e5gor d\u00e5 spr\u00e5ken ofta f\u00f6rs\u00f6ker efterlikna vanlig engelska.<\/p>\n\n\n\n

stateDiagram-v2\n        State1: 1 Gen\n        State1 --> State2\n        State2: 2 Gen\n        note left of State2 : Assembly\n        State2 --> State3\n        State3: 3 Gen\n        note left of State3 : C, Java, Python\n        State3 --> State4\n        State4: 4 Gen\n        note left of State4 : SQL, ABAP\n        State4 --> State5\n        State5: 5 Gen\n        note left of State5 : AI? LLM?<\/pre>\n\n\n\n
Tanken \u00e4r bra och det \u00e4r ocks\u00e5 vad dagens low-code<\/a> l\u00f6sningar f\u00f6rs\u00f6ker g\u00f6ra igen. Allts\u00e5 h\u00f6ja abstraktionsniv\u00e5n med hj\u00e4lp av f\u00e4rdigskriven kod som f\u00f6rhoppningsvis blir p\u00e5 en h\u00f6gre och enklare niv\u00e5. Detta nya verktyg kan vara allt fr\u00e5n lite f\u00e4rdiga funktioner<\/a> i ett befintligt spr\u00e5k eller en hel plattform d\u00e4r du drar och sl\u00e4pper<\/a> grafiska objekt p\u00e5 varandra som ett s\u00e4tt att programmera maskinen.<\/p>\n\n\n\n
<\/p>\n\n\n\n
Men ett lager till av abstraktion har ett pris. Det kan vara om\u00f6jligt att beskriva en l\u00f6sning p\u00e5 vissa problem med den detaljrikedom som funnits till hand med ett ”vanligt” programmeringsspr\u00e5k p\u00e5 en l\u00e4gre niv\u00e5. Alternativt blir den SQL-baserade l\u00f6sningen on\u00f6digt komplex f\u00f6r att det inte \u00e4r m\u00f6jligt att \u00e5teranv\u00e4nda kod p\u00e5 samma s\u00e4tt.<\/p>\n\n\n\n
Detta leder mig till k\u00e4rnan av detta inl\u00e4gg: Stored procedures<\/a> som spr\u00e5k i backend. Allts\u00e5 system d\u00e4r det mesta av aff\u00e4rslogiken (det som \u00e4r v\u00e4rt pengar) \u00e4r inl\u00e5st i SQL, ett spr\u00e5k d\u00e4r inga satsningar g\u00f6rs p\u00e5 ergonomin f\u00f6r utvecklaren. Ett spr\u00e5k som saknar arv, klasser, inkapsling, reflektion, generics och annat g\u00f6tt som \u00f6vriga spr\u00e5k uppfinner just f\u00f6r att hantera en skenande komplexitet.<\/p>\n\n\n\n
\n
Let me put this another way: Stack Overflow has only 1 stored procedure in the database and I intend to move that last vestige into code.<\/p>\nhttps:\/\/nickcraver.com\/blog\/2016\/02\/17\/stack-overflow-the-architecture-2016-edition\/<\/a><\/cite><\/blockquote>\n\n\n\n
Ovan \u00e4r citat fr\u00e5n arkitekten p\u00e5 Stackoverflow och vad denna k\u00e4nner stored procedures har f\u00f6r plats i systemet.<\/p>\n\n\n\n
\n\n\n\n
Hur kom vi hit?<\/h2>\n\n\n\n
P\u00e5 90-talet n\u00e4r relationsdatabaser fick ordentligt genomslag s\u00e5 gissar jag att det s\u00e5gs som en smidig l\u00f6sning att uppn\u00e5 en klient-server arkitektur genom att skapa en ”fet klient” i till exempel VB eller C++ som blev h\u00e5rt knyten till sin server som ocks\u00e5 samtidigt \u00e4r en databas d\u00e4r ”koden” \u00e4r i form av stora m\u00e4ngder SQL procedurer.<\/p>\n\n\n\n
M\u00e5let var att avlasta de kanske svagare klientdatorerna med att de (misst\u00e4nkt) allra tyngsta funktionerna k\u00f6rdes direkt i databasen, p\u00e5 en annan maskin. Samt att l\u00f6ftet var ocks\u00e5 att fj\u00e4rde generationens spr\u00e5k skulle vara mer l\u00e4mpade och kraftfullare i att beskriva aff\u00e4rsprocesserna i mjukvaran.<\/p>\n\n\n\n
graph LR; \nKlient1-->|SQL|D[(Databas)] \nKlient2-->|SQL|D \nKlient3-->|SQL|D \nE(ev. Servertj\u00e4nst)-->|SQL|D <\/pre>\n\n\n\n
Klienterna h\u00e4mtade data och utf\u00f6rde f\u00f6r\u00e4ndringar i databasen genom att skicka SQL str\u00e4ngar synkront ”\u00f6ver tr\u00e5den”. <\/p>\n\n\n\n
Resultatet blev att system byggdes upp med tv\u00e5 mycket olika programmeringsspr\u00e5k<\/strong>. D\u00e4r det ena f\u00f6rmodligen var ett tredje generations objekt-orienterat spr\u00e5k i klienten, och det andra ett fj\u00e4rde generations data-fr\u00e5ge spr\u00e5k. <\/p>\n\n\n\n
pie title Andel programmeringsspr\u00e5k i ett hypotetiskt system\n    \"VB\" : 15\n    \"SQL\" : 85<\/pre>\n\n\n\n
Databasen kan inte i denna arkitektur vara den f\u00f6rsta att reagera och initiera kontakt tillbaka till en klient n\u00e4r n\u00e5gon ny h\u00e4ndelse intr\u00e4ffat. Klienterna f\u00e5r ist\u00e4llet konstant polla dabasen efter intressanta \u00e4ndringar att reagera p\u00e5. \u00d6nskar anv\u00e4ndarna att systemet skall bli rappare \u00e4r enda alternativet att klienterna pollar h\u00e5rdare. Detta \u00e4r bara en form av busy waiting<\/a>, d\u00e5ligt f\u00f6r milj\u00f6n.<\/p>\n\n\n\n
Att bygga ett system med tv\u00e5 s\u00e5 pass olika spr\u00e5k \u00e4r en on\u00f6dig kostnad i den mentala energi det g\u00e5r \u00e5t att byta mellan dessa. F\u00f6rutom att spr\u00e5ken som anv\u00e4nds skiftar konstant s\u00e5 skiftar ocks\u00e5 verktygen som anv\u00e4nds, s\u00e4ttet \u00e4ndringar testas, s\u00e4ttet \u00e4ndringar versionshanteras p\u00e5 och s\u00e4ttet  \u00e4ndringar transporteras till produktion.<\/p>\n\n\n\n
\n