{"id":83649,"date":"2020-06-02T07:42:21","date_gmt":"2020-06-02T05:42:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/database-as-sode-experience"},"modified":"2020-06-02T07:42:21","modified_gmt":"2020-06-02T05:42:21","slug":"database-as-sode-experience","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/database-as-sode-experience","title":{"rendered":"\u00abDatabase as Code\u00bb Erfarenhet","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"\u00abDatabase<\/p>\n

<\/p>\n

SQL, vad kan vara enklare? Vi kan alla skriva en enkel fr\u00e5ga \u2014 vi skriver select<\/em><\/strong>, listar de n\u00f6dv\u00e4ndiga kolumnerna, sedan fr\u00e5n<\/em><\/strong>, tabellnamnet, lite villkor i d\u00e4r<\/em><\/strong> och allt \u2014 d\u00e5 har vi anv\u00e4ndbara data i fickan, n\u00e4stan oavsett vilken databas som ligger under huven (eller kanske inte ens \u00e4r en databas) Inte en databas alls<\/a><\/noindex>). Som ett resultat kan arbetet med n\u00e4stan vilken datak\u00e4lla som helst (relationell eller inte) ses ur en vanlig kods perspektiv (med allt som f\u00f6ljer \u2014 versionshantering, kodgranskning, statisk analys, automatiserade tester och allt det d\u00e4r). Och detta g\u00e4ller inte bara sj\u00e4lva datan, scheman och migreringar, utan \u00f6verlag hela livscykeln f\u00f6r datalagret. I denna artikel kommer vi att diskutera de vardagliga uppgifterna och problemen med arbete med olika databaser under linsen av \"database as code\".<\/p>\n

<\/p>\n

Och vi b\u00f6rjar direkt med ORM<\/a><\/noindex>. De f\u00f6rsta striderna av typen \"SQL vs ORM\" observerades redan i f\u00f6re Peter den stores tid<\/a><\/noindex>.<\/p>\n

<\/a><\/noindex><\/p>\n

Objekt-relationell mappning<\/h5>\n

<\/p>\n

F\u00f6respr\u00e5kare av ORM v\u00e4rderar traditionellt hastighet och enkelhet i utvecklingen, oberoende av databasen och renheten i koden. F\u00f6r m\u00e5nga av oss ser koden f\u00f6r databasarbetet (och ofta sj\u00e4lva databasen)<\/p>\n

<\/p>\n

ser vanligtvis ut ungef\u00e4r s\u00e5 h\u00e4r\u2026<\/b><\/p>\n

@Entity\n@Table(name = \"stock\", catalog = \"maindb\", uniqueConstraints = {\n        @UniqueConstraint(columnNames = \"STOCK_NAME\"),\n        @UniqueConstraint(columnNames = \"STOCK_CODE\") })\npublic class Stock implements java.io.Serializable {\n\n    @Id\n    @GeneratedValue(strategy = IDENTITY)\n    @Column(name = \"STOCK_ID\", unique = true, nullable = false)\n    public Integer getStockId() {\n        return this.stockId;\n    }\n  ...<\/code><\/pre>\n
<\/p>\n
Modellen \u00e4r prydd med smarta annotationer, och n\u00e5gonstans bakom kulisserna genererar och exekverar den \u00e5terh\u00e5llsamma ORM:en tonvis med SQL-kod. F\u00f6r att s\u00e4ga s\u00e5, f\u00f6rs\u00f6ker utvecklarna med alla medel att skydda sig fr\u00e5n sin databas med kilometer av abstraktioner, vilket tyder p\u00e5 en viss \"SQL-hatred\"<\/a><\/noindex>.<\/p>\n
<\/p>\n
P\u00e5 andra sidan barrikaderna noterar anh\u00e4ngare av ren \"handmade\"-SQL m\u00f6jligheten att pressa ut maximal prestanda fr\u00e5n sin DBMS utan ytterligare lager och abstraktioner. Detta leder till \"data-centric\" projekt d\u00e4r databasen hanteras av specialutbildade personer (de kallas ocks\u00e5 \"databasister\", \"databasfolk\", \"databaskunniga\" och s\u00e5 vidare), och utvecklarna f\u00e5r bara \"dra\" f\u00e4rdiga vyer och lagrade procedurer utan att g\u00e5 in i detaljer.<\/p>\n
<\/p>\n
Vad s\u00e4gs om att ta det b\u00e4sta fr\u00e5n tv\u00e5 v\u00e4rldar? Hur det g\u00f6rs i det fantastiska verktyget med det livsbejakande namnet Yesql<\/a><\/noindex>. Jag kommer att ge ett par rader fr\u00e5n den \u00f6vergripande konceptet i min fria \u00f6vers\u00e4ttning, och mer detaljerat kan man bekanta sig med det h\u00e4r<\/a><\/noindex>.<\/p>\n
<\/p>\n
Clojure \u00e4r ett fantastiskt spr\u00e5k f\u00f6r att skapa DSL:er, men SQL i sig \u00e4r redan en kraftfull DSL, och vi beh\u00f6ver inte ytterligare en. S-expressioner \u00e4r fantastiska, men h\u00e4r tillf\u00f6r de inget nytt. I slut\u00e4ndan f\u00e5r vi parenteser f\u00f6r parentesernas skull. H\u00e5ller du inte med? D\u00e5 kan du v\u00e4nta p\u00e5 det \u00f6gonblick d\u00e5 abstraktionen \u00f6ver databasen l\u00e4cker, och du b\u00f6rjar kampen med funktionen. (raw-sql)<\/em><\/p>\n
Och vad ska vi g\u00f6ra? L\u00e5t oss l\u00e5ta SQL f\u00f6rbli vanligt SQL \u2014 en fil f\u00f6r en f\u00f6rfr\u00e5gan:<\/p><\/blockquote>\n
<\/p>\n
-- namn: users-by-country\nselect *\n  from users\n where country_code = :country_code<\/code><\/pre>\n
<\/p>\n
\u2026 och l\u00e4s sedan denna fil, och omvandla den till en vanlig Clojure-funktion:<\/p><\/blockquote>\n
<\/p>\n
(defqueries \"some\/where\/users_by_country.sql\"\n   {:connection db-spec})\n\n;;; En funktion med namnet `users-by-country` har skapats.\n;;; L\u00e5t oss anv\u00e4nda den:\n(users-by-country {:country_code \"GB\"})\n;=> ({:name \"Kris\" :country_code \"GB\" ...} ...)<\/code><\/pre>\n
<\/p>\n
Genom att f\u00f6lja principen \"SQL separat, Clojure separat\" f\u00e5r du:<\/p>\n