{"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":"\u201eDatenbank als Code\u201c Erfahrung","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"\u201eDatenbank<\/p>\n

<\/p>\n

SQL, was k\u00f6nnte einfacher sein? Jeder von uns kann eine einfache Anfrage schreiben \u2013 wir geben ein select<\/em><\/strong>, listen die ben\u00f6tigten Spalten auf, dann from<\/em><\/strong>, den Tabellennamen, ein paar Bedingungen in wo<\/em><\/strong> und schon \u2013 n\u00fctzliche Daten sind in unserer Tasche, fast unabh\u00e4ngig davon, welche DBMS gerade im Hintergrund l\u00e4uft (oder vielleicht ist es sogar gar kein DBMS<\/a><\/noindex>). In der Folge kann die Arbeit mit nahezu jeder Datenquelle (relational oder nicht) aus der Sicht gew\u00f6hnlichen Codes betrachtet werden (mit all seinen Konsequenzen \u2014 Versionskontrolle, Code-Review, statische Analyse, automatisierte Tests und all das). Dies betrifft nicht nur die Daten selbst, Schemata und Migrationen, sondern das gesamte Leben des Repositories. In diesem Artikel sprechen wir \u00fcber allt\u00e4gliche Aufgaben und Probleme bei der Arbeit mit verschiedenen Datenbanken aus der Perspektive von \"Datenbank als Code\".<\/p>\n

<\/p>\n

Und wir beginnen direkt mit ORM<\/a><\/noindex>. Die ersten K\u00e4mpfe im Stil von \"SQL gegen ORM\" wurden bereits beobachtet in vorkolonialem Russland<\/a><\/noindex>.<\/p>\n

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

Objekt-Relationales Mapping<\/h5>\n

<\/p>\n

Bef\u00fcrworter von ORM sch\u00e4tzen traditionell die Geschwindigkeit und Einfachheit der Entwicklung, die Unabh\u00e4ngigkeit von DBMS und die Klarheit des Codes. F\u00fcr viele von uns sieht der Code zur Arbeit mit der Datenbank (und oft auch die Datenbank selbst)<\/p>\n

<\/p>\n

sieht normalerweise ungef\u00e4hr 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
Das Modell ist mit intelligenten Annotationen ausgestattet, w\u00e4hrend im Hintergrund ein t\u00fcchtiger ORM Unmengen von SQL-Code generiert und ausf\u00fchrt. Es sei erw\u00e4hnt, dass Entwickler alles daran setzen, sich durch Kilometer von Abstraktionen von ihrer Datenbank abzugrenzen, was auf ein gewisses \"SQL-Diskriminierung\"<\/a><\/noindex>.<\/p>\n
<\/p>\n
Auf der anderen Seite der Barrikade betonen die Bef\u00fcrworter von purem \"handmade\"-SQL die M\u00f6glichkeit, die volle Leistung ihrer Datenbank ohne zus\u00e4tzliche Schichten und Abstraktionen auszusch\u00f6pfen. Infolgedessen entstehen \"data-centric\" Projekte, in denen speziell ausgebildete Personen (die auch als \"Datenbank-Spezialisten\", \"Datenbankentwickler\" oder \"Datenbankexperten\" bekannt sind) sich um die Datenbanken k\u00fcmmern, w\u00e4hrend die Entwickler lediglich vorbereitete Views und Stored Procedures nutzen, ohne sich mit den Details auseinanderzusetzen.<\/p>\n
<\/p>\n
Was w\u00e4re, wenn wir das Beste aus beiden Welten kombinieren? So wie es mit dem wunderbaren Werkzeug mit dem lebensbejahenden Namen Yesql<\/a><\/noindex>. Ich werde ein paar Zeilen aus dem allgemeinen Konzept in meiner freien \u00dcbersetzung anf\u00fchren; f\u00fcr detailliertere Informationen k\u00f6nnen Sie sich damit vertraut machen. hier<\/a><\/noindex>.<\/p>\n
<\/p>\n
Clojure ist eine gro\u00dfartige Sprache zur Erstellung von DSLs, aber SQL ist bereits ein erstklassiger DSL und wir brauchen keinen weiteren. S-Ausdr\u00fccke sind wunderbar, aber hier bringen sie nichts Neues. Am Ende haben wir Klammern um der Klammern willen. Stimmen Sie nicht zu? Warten Sie den Moment ab, wenn die Abstraktion \u00fcber der Datenbank zu lecken beginnt und Sie in den Kampf mit der Funktion eintreten. (raw-sql)<\/em><\/p>\n
Und was tun? Lassen Sie uns SQL einfach SQL sein \u2014 eine Datei pro Anfrage:<\/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 dann lesen Sie diese Datei, indem Sie sie in eine regul\u00e4re Clojure-Funktion umwandeln:<\/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 diese verwenden:\n(users-by-country {:country_code \"GB\"})\n;=> ({:name \"Kris\" :country_code \"GB\" ...} ...)<\/code><\/pre>\n
<\/p>\n
Wenn Sie nach dem Prinzip \"SQL separat, Clojure separat\" arbeiten, erhalten Sie:<\/p>\n