{"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\/de\/blog\/administrirovanie\/database-as-sode-experience","title":{"rendered":"\u201eDatabase as Code\u201c Experience","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"\u201eDatabase<\/p>\n

<\/p>\n

SQL, was k\u00f6nnte einfacher sein? Jeder von uns kann eine einfache Abfrage schreiben \u2013 wir tippen select<\/em><\/strong>, listen die ben\u00f6tigten Spalten auf, dann from<\/em><\/strong>, der Tabellenname, ein bisschen Bedingungen in where<\/em><\/strong> und fertig \u2013 n\u00fctzliche Daten sind in unserer Tasche, und das (fast) unabh\u00e4ngig davon, welche DBMS gerade unter der Haube steckt (oder vielleicht gar keine DBMS)<\/a><\/noindex>). In der Folge kann die Arbeit mit praktisch jeder Datenquelle (relationale und nicht-relationale) als normaler Code betrachtet werden (mit all den Konsequenzen \u2014 Versionskontrolle, Code-Review, statische Analyse, automatisierte Tests und all diesen Dingen). Und das betrifft nicht nur die Daten selbst, Schemata und Migrationen, sondern die gesamte Lebensweise des Speichers. In diesem Artikel werden wir \u00fcber allt\u00e4gliche Aufgaben und Probleme bei der Arbeit mit verschiedenen Datenbanken im Kontext von "database as code" sprechen.<\/p>\n

<\/p>\n

Und wir fangen gleich mit ORM<\/a><\/noindex>. Die ersten K\u00e4mpfe der Art "SQL vs ORM" wurden bereits beobachtet in vor-petrinischen Russland<\/a><\/noindex>.<\/p>\n

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

bemerkenswert.<\/h5>\n

<\/p>\n

Objekt-relationale Abbildung<\/p>\n

<\/p>\n

sieht normalerweise etwa so aus\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
@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  ... "SQL der Abneigung"<\/a><\/noindex>.<\/p>\n
<\/p>\n
Auf der anderen Seite des Barrikades weisen die Bef\u00fcrworter reinen "handmade"-SQL darauf hin, dass man alle M\u00f6glichkeiten seiner DBMS ohne zus\u00e4tzliche Schichten und Abstraktionen aussch\u00f6pfen kann. Infolgedessen entstehen "data-centric" Projekte, in denen eigens geschulte Personen (sie sind auch die "DB-Menschen", auch die "Datenbankleute", auch die "DB-Fachleute" usw.) sich um die Daten k\u00fcmmern, w\u00e4hrend die Entwickler nur bereitstehen, um vorbereitete Views und gespeicherte Prozeduren abzurufen, ohne sich in die Details zu vertiefen.<\/p>\n
<\/p>\n
Hinzu kommt, dass auf der anderen Seite der Barrikaden die Bef\u00fcrworter von reinem \"handmade\"-SQL die M\u00f6glichkeit hervorheben, aus ihrer DBMS alles herauszuholen, ohne zus\u00e4tzliche Schichten und Abstraktionen. Infolgedessen entstehen \"data-centric\"-Projekte, in denen speziell ausgebildete Personen sich um die Datenbank k\u00fcmmern (sie sind auch 'Basi\u015bci', 'Baziwiks', 'Basiendik', usw.), und den Entwicklern bleibt nur, die fertigen Views und gespeicherten Prozeduren zu 'ziehen', ohne ins Detail zu gehen. Und was, wenn wir das Beste aus beiden Welten nehmen? So wie es im bemerkenswerten Tool mit dem lebensbejahenden Namen<\/a><\/noindex>Yesql gemacht wird. Ich werde ein paar Zeilen aus dem Gesamtkonzept in meiner freien \u00dcbersetzung anf\u00fchren, und anhand dieser kann man sich n\u00e4her damit besch\u00e4ftigen. hier<\/a><\/noindex>.<\/p>\n
<\/p>\n
Clojure ist eine gro\u00dfartige Sprache zur Erstellung von DSLs, aber SQL ist bereits von Natur aus eine tolle DSL, und wir brauchen keine weitere. S-Ausdr\u00fccke sind wunderbar, aber hier bringen sie nichts Neues. Am Ende bekommen wir Klammern, nur um der Klammer willen. Nicht einverstanden? Dann warten Sie, bis die Abstraktion \u00fcber der Datenbank undicht wird und Sie anfangen, mit der Funktion zu k\u00e4mpfen. (raw-sql)<\/em><\/p>\n
Und was tun? Lassen Sie uns SQL einfach SQL lassen \u2014 eine Datei f\u00fcr eine Abfrage:<\/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 und lesen Sie dann diese Datei, um sie in eine gew\u00f6hnliche Clojure-Funktion zu verwandeln:<\/p><\/blockquote>\n
<\/p>\n
(defqueries "some\\\/where\\\/users_by_country.sql"\n   {:connection db-spec})\n\n;;; Eine Funktion mit dem Namen `users-by-country` wurde erstellt.\n;;; Lassen Sie uns sie verwenden:\n(users-by-country {:country_code "GB"})\n;=> ({:name "Kris" :country_code "GB" ...} ...)<\/code><\/pre>\n
<\/p>\n
Indem Sie sich an das Prinzip "SQL getrennt, Clojure getrennt" halten, erhalten Sie:<\/p>\n