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

\"Esperienza<\/p>\n

<\/p>\n

SQL, cosa pu\u00f2 essere pi\u00f9 semplice? Ognuno di noi pu\u00f2 scrivere una semplice query \u2014 digitiamo select<\/em><\/strong>, elenchiamo le colonne necessarie, poi from<\/em><\/strong>, il nome della tabella, qualche condizione in dove<\/em><\/strong> e voil\u00e0 \u2014 i dati utili sono a portata di mano, praticamente (quasi) indipendentemente dal tipo di DBMS che sta funzionando sotto il cofano (o forse non \u00e8 nemmeno un DBMS)<\/a><\/noindex>). Di conseguenza, il lavoro con praticamente qualsiasi sorgente di dati (relazionale e non) pu\u00f2 essere considerato dal punto di vista del codice ordinario (con tutte le conseguenze \u2014 controllo della versione, revisione del codice, analisi statica, test automatici e tutto il resto). E questo riguarda non solo i dati stessi, gli schemi e le migrazioni, ma anche tutta l'attivit\u00e0 del magazzino. In questo articolo parleremo delle attivit\u00e0 quotidiane e dei problemi legati al lavoro con diversi database sotto la lente di "database as code".<\/p>\n

<\/p>\n

E iniziamo proprio con ORM<\/a><\/noindex>. Le prime battaglie del tipo "SQL vs ORM" sono state notate gi\u00e0 nel Rus' pre-petroviana<\/a><\/noindex>.<\/p>\n

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

Mapping oggetto-relazionale<\/h5>\n

<\/p>\n

I sostenitori dell'ORM tradizionalmente apprezzano la velocit\u00e0 e la semplicit\u00e0 dello sviluppo, l'indipendenza dal DBMS e la pulizia del codice. Per molti di noi, il codice per l'interazione con il DB (e spesso il DB stesso)<\/p>\n

<\/p>\n

di solito appare pi\u00f9 o meno cos\u00ec\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
Il modello \u00e8 arricchito con annotazioni intelligenti, mentre dietro le quinte un valoroso ORM genera ed esegue tonnellate di codice SQL. A proposito, gli sviluppatori si sforzano di separarsi dal loro DB con chilometri di astrazioni, il che indica una certa "SQL della discordia"<\/a><\/noindex>.<\/p>\n
<\/p>\n
Dall'altra parte delle barricate, i sostenitori del puro SQL \"handmade\" sottolineano la possibilit\u00e0 di spremere il massimo dal proprio DBMS senza strati e astrazioni aggiuntive. Di conseguenza, nascono progetti \"data-centric\", dove i database sono gestiti da persone appositamente formate (chiamate anche \"database specialist\", \"database engineer\", oppure \"database admin\"), mentre agli sviluppatori resta solo il compito di \"interrogare\" le viste pronte e le procedure memorizzate, senza entrare nei dettagli.<\/p>\n
<\/p>\n
E se prendessimo il meglio di entrambi i mondi? Come \u00e8 realizzato nel meraviglioso strumento dal nome incoraggiante Yesql<\/a><\/noindex>. Ecco un paio di frasi dall'idea generale in una mia libera traduzione, per approfondire ulteriormente il tema, si pu\u00f2 leggere di pi\u00f9. qui<\/a><\/noindex>.<\/p>\n
<\/p>\n
Clojure \u00e8 un linguaggio fantastico per creare DSL, ma SQL di per s\u00e9 \u00e8 gi\u00e0 un ottimo DSL, e non abbiamo bisogno di un altro. Le S-espressioni sono belle, ma qui non aggiungono nulla di nuovo. Risultato: parentesi per il gusto di avere parentesi. Non sei d'accordo? Aspetta solo che l'astrazione sul DB inizi a perdere colpi, e comincerai a combattere contro le funzioni. (raw-sql)<\/em><\/p>\n
E cosa fare? Lasciamo SQL cos\u00ec com'\u00e8 - un file per ogni richiesta:<\/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 e poi leggete questo file, trasformandolo in una normale funzione Clojure:<\/p><\/blockquote>\n
<\/p>\n
(defqueries \"some\/where\/users_by_country.sql\"\n   {:connection db-spec})\n\n;;; \u00c8 stata creata una funzione con il nome `users-by-country`.\n;;; Usiamola:\n(users-by-country {:country_code \"GB\"})\n;=> ({:name \"Kris\" :country_code \"GB\" ...} ...)<\/code><\/pre>\n
<\/p>\n
Seguendo il principio \"SQL separato, Clojure separato\", ottieni:<\/p>\n