{"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\/da\/blog\/administrirovanie\/database-as-sode-experience","title":{"rendered":"\u00abDatabase as Code\u00bb oplevelse","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"\u00abDatabase<\/p>\n

<\/p>\n

SQL, hvad kan v\u00e6re lettere? Hver af os kan skrive en simpel foresp\u00f8rgsel \u2014 vi indtaster select<\/em><\/strong>, angiver de n\u00f8dvendige kolonner, s\u00e5 fra<\/em><\/strong>, tabelnavnet, lidt betingelser i where<\/em><\/strong> og det hele \u2014 de nyttige data har vi i lommen, n\u00e6sten uafh\u00e6ngigt af hvilken DBMS der er under h\u00e6tten (eller m\u00e5ske endda slet ikke en DBMS<\/a><\/noindex>). Derfor kan arbejdet med n\u00e6sten enhver datakilde (b\u00e5de relationel og ikke s\u00e5 meget) betragtes ud fra et almindeligt kodeperspektiv (med alle de d\u00e9r konsekvenser \u2014 versionskontrol, kodegennemgang, statisk analyse, automatiserede tests og s\u00e5 videre). Og dette g\u00e6lder ikke kun for selve dataene, skemaerne og migrationerne, men generelt for hele livscyklussen af lageret. I denne artikel vil vi tale om de daglige opgaver og udfordringer i arbejdet med forskellige databaser med fokus p\u00e5 "database as code".<\/p>\n

<\/p>\n

Og lad os starte lige med ORM<\/a><\/noindex>. De f\u00f8rste kampe i stil med "SQL vs ORM" blev allerede bem\u00e6rket tilbage i f\u00f8r-peter-tiden i Rusland<\/a><\/noindex>.<\/p>\n

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

Objekt-relationel mapping<\/h5>\n

<\/p>\n

Tilh\u00e6ngere af ORM v\u00e6rds\u00e6tter traditionelt hastighed og enkelhed i udviklingen, uafh\u00e6ngighed fra DBMS og kodekvalitet. For mange af os ser koden til at arbejde med databaser (og ofte selve databasen)<\/p>\n

<\/p>\n

ser normalt cirka s\u00e5dan her ud\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 er udstyret med smarte annotationer, og et sted backstage genererer og udf\u00f8rer den tapre ORM ton af SQL-kode. For \u00f8vrigt fors\u00f8ger udviklerne med alle midler at afsk\u00e6rme sig fra deres DB med kilometer af abstraktioner, hvilket indikerer en form for "SQL-had"<\/a><\/noindex>.<\/p>\n
<\/p>\n
P\u00e5 den anden side af barrikaderne bem\u00e6rker tilh\u00e6ngerne af ren "handmade"-SQL muligheden for at f\u00e5 det maksimale ud af deres DBMS uden yderligere lag og abstraktioner. Hvilket resulterer i "data-centric" projekter, hvor databasen h\u00e5ndteres af specialuddannede folk (de kaldes ogs\u00e5 "databasem\u00e6nd", "databaser" og s\u00e5 videre), mens udviklerne kun har til opgave at "tr\u00e6kke" f\u00e6rdige visninger og lagrede procedurer uden at g\u00e5 i detaljer.<\/p>\n
<\/p>\n
Hvad hvis vi tager det bedste fra begge verdener? Hvordan dette er gjort i det fantastiske v\u00e6rkt\u00f8j med den livsbekr\u00e6ftende titel Yesql<\/a><\/noindex>. Jeg vil give et par linjer fra den overordnede koncept i min frie overs\u00e6ttelse, og mere om den kan man l\u00e6se her<\/a><\/noindex>.<\/p>\n
<\/p>\n
Clojure er et fantastisk sprog til at skabe DSL'er, men SQL er allerede et fantastisk DSL i sig selv, s\u00e5 vi har ikke brug for endnu et. S-udtryk er sk\u00f8nne, men her tilf\u00f8jer de ikke noget nyt. I sidste ende f\u00e5r vi parenteser for parentesernes skyld. Er du uenig? S\u00e5 vent til den abstraktion, der ligger over databasen, begynder at l\u00e6kke, og du starter kampen med funktionen (raw-sql)<\/em><\/p>\n
Og hvad skal vi s\u00e5 g\u00f8re? Lad os holde SQL som almindelig SQL \u2014 \u00e9n fil til \u00e9n foresp\u00f8rgsel:<\/p><\/blockquote>\n
<\/p>\n
-- name: users-by-country\nselect *\n  from users\n where country_code = :country_code<\/code><\/pre>\n
<\/p>\n
\u2026 og l\u00e6s derefter denne fil, og g\u00f8r den til en almindelig Clojure-funktion:<\/p><\/blockquote>\n
<\/p>\n
(defqueries "some\/where\/users_by_country.sql"\n   {:connection db-spec})\n\n;;; En funktion med navnet `users-by-country` er blevet oprettet.\n;;; Lad os bruge den:\n(users-by-country {:country_code "GB"})\n;=> ({:name "Kris" :country_code "GB" ...} ...)<\/code><\/pre>\n
<\/p>\n
Ved at holde fast i princippet "SQL for sig selv, Clojure for sig selv", f\u00e5r du:<\/p>\n