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

\"\u00abDatabase<\/p>\n

<\/p>\n

SQL, wat kan er eenvoudiger zijn? Ieder van ons kan een eenvoudige query schrijven - we typen select<\/em><\/strong>, sommen de benodigde kolommen op, dan van<\/em><\/strong>, de naam van de tabel, een beetje voorwaarden in waar<\/em><\/strong> en dat is het - we hebben nuttige gegevens in onze handen, bijna (bijna) ongeacht welke DBMS er onder de motorkap draait (en misschien is het ook geen DBMS \u00fcberhaupt<\/a><\/noindex>). Hierdoor kan de werking met vrijwel elke gegevensbron (relationeel of niet) worden bekeken vanuit het perspectief van gewone code (met alle gevolgen van dien \u2014 versiebeheer, code-review, statische analyse, automatische tests, en zo verder). Dit betreft niet alleen de gegevens zelf, schema's en migraties, maar eigenlijk de hele levenscyclus van de opslag. In dit artikel bespreken we de dagelijkse taken en problemen bij het werken met verschillende databases met de focus op 'database as code'.<\/p>\n

<\/p>\n

We beginnen met ORM<\/a><\/noindex>. De eerste gevechten van het type 'SQL vs ORM' werden al opgemerkt in pre-Peter's Rusland<\/a><\/noindex>.<\/p>\n

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

Object-relationele mapping<\/h5>\n

<\/p>\n

Voorstanders van ORM waarderen traditioneel de snelheid en eenvoud van ontwikkeling, onafhankelijkheid van DBMS en de netheid van de code. Voor velen van ons ziet de code die met de database werkt (en vaak ook de database zelf)<\/p>\n

<\/p>\n

ziet er meestal ongeveer zo uit\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
Het model is uitgerust met slimme annotaties, terwijl ergens achter de schermen de dappere ORM tonnen aan SQL-code genereert en uitvoert. Trouwens, ontwikkelaars proberen met alle macht zich te omgeven met kilometers aan abstracties van hun database, wat wijst op een zekere \"SQL haat\"<\/a><\/noindex>.<\/p>\n
<\/p>\n
Aan de andere kant van de barricade wijzen voorstanders van puur 'handmade'-SQL op de mogelijkheid om het meeste uit hun DBMS te halen zonder extra lagen en abstracties. Dit resulteert in 'data-centric' projecten, waarbij speciaal opgeleide mensen (zij zijn 'database deskundigen', ook wel 'gegevensspecialisten' of 'databasetechnici' genoemd) zich met de database bezighouden, terwijl ontwikkelaars alleen nog maar de kant-en-klare views en opgeslagen procedures hoeven aan te roepen zonder in de details te duiken.<\/p>\n
<\/p>\n
Wat als we het beste van twee werelden combineren? Zoals gedaan in het geweldige hulpmiddel met de levensbevestigende naam Yesql<\/a><\/noindex>. Ik zal een paar zinnen delen uit het algemene concept in mijn vrije vertaling, en je kunt er meer over leren. hier<\/a><\/noindex>.<\/p>\n
<\/p>\n
Clojure is een geweldige taal voor het maken van DSL's, maar SQL op zichzelf is al een geweldige DSL, en we hebben er niet nog \u00e9\u00e9n nodig. S-expressies zijn prachtig, maar hier voegen ze niets nieuws toe. Uiteindelijk krijgen we haakjes omwille van haakjes. Het oneens? Wacht dan tot het moment dat de abstractie boven de DB lekt, en je moet worstelen met de functie (raw-sql)<\/em><\/p>\n
En wat doen we? Laten we SQL gewoon SQL laten zijn \u2014 \u00e9\u00e9n bestand voor \u00e9\u00e9n aanvraag:<\/p><\/blockquote>\n
<\/p>\n
-- naam: users-by-country\nselect *\n  from users\n where country_code = :country_code<\/code><\/pre>\n
<\/p>\n
\u2026 en lees dat bestand vervolgens, en zet het om in een gewone Clojure-functie:<\/p><\/blockquote>\n
<\/p>\n
(defqueries \"some\/where\/users_by_country.sql\"\n   {:connection db-spec})\n\n;;; Een functie met de naam `users-by-country` is aangemaakt.\n;;; Laten we deze gebruiken:\n(users-by-country {:country_code \"GB\"})\n;=> ({:name \"Kris\" :country_code \"GB\" ...} ...)<\/code><\/pre>\n
<\/p>\n
Door het principe van \"SQL apart, Clojure apart\" aan te houden, krijgt u:<\/p>\n