{"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 'Database as Code'","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 digitando select<\/em><\/strong>, elencando le colonne necessarie, poi da<\/em><\/strong>, il nome della tabella, qualche condizione in where<\/em><\/strong> e voil\u00e0 \u2014 i dati utili sono nella nostra tasca, quasi indipendentemente dal tipo di DBMS che stiamo utilizzando nel backend (o forse non \u00e8 nemmeno un DBMS) non \u00e8 affatto un DBMS<\/a><\/noindex>). Grazie a questo, il lavoro con praticamente qualsiasi fonte di dati (relazionale e non solo) pu\u00f2 essere visto da una prospettiva di codice normale (con tutte le conseguenze \u2014 controllo 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 in generale l'intera attivit\u00e0 del repository. In questo articolo parleremo delle attivit\u00e0 quotidiane e dei problemi nel lavorare con diversi database sotto il mirino del 'database as code'.<\/p>\n

<\/p>\n

E iniziamo subito con ORM<\/a><\/noindex>. I primi scontri del tipo 'SQL vs ORM' sono stati notati gi\u00e0 nel Russia prerivoluzionaria<\/a><\/noindex>.<\/p>\n

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

Il mapping oggetto-relazionale<\/h5>\n

<\/p>\n

I sostenitori dell'ORM tradizionalmente apprezzano la velocit\u00e0 e la semplicit\u00e0 di sviluppo, l'indipendenza dal DBMS e la pulizia del codice. Per molti di noi, il codice per lavorare con il database (e spesso anche il database 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 ricco di annotazioni intelligenti, mentre dietro le quinte il valoroso ORM genera ed esegue tonnellate di codice SQL. A proposito, gli sviluppatori cercano in tutti i modi di isolarsi dal loro database attraverso chilometri di astrazioni, il che indica una certa \"SQL dell'odio\"<\/a><\/noindex>.<\/p>\n
<\/p>\n
Dall'altra parte delle barricate, i sostenitori del puro 'handmade' SQL evidenziano la possibilit\u00e0 di spremere ogni goccia dalla propria SGBD senza strati e astrazioni aggiuntive. Da ci\u00f2 nascono progetti 'data-centric', in cui i database sono gestiti da persone appositamente addestrate (i cosiddetti 'db specialist', 'database experts', ecc.), mentre agli sviluppatori resta solo il compito di 'estrarre' le viste pronte e le procedure archiviate, senza entrare nei dettagli.<\/p>\n
<\/p>\n
E se prendessimo il meglio di entrambi i mondi? Come \u00e8 stato fatto in questo straordinario strumento con un nome che d\u00e0 fiducia, Yesql<\/a><\/noindex>. Riporto un paio di frasi dalla concettualizzazione generale in una mia libera traduzione, e per una panoramica pi\u00f9 dettagliata, si pu\u00f2 approfondire qui<\/a><\/noindex>.<\/p>\n
<\/p>\n
Clojure \u00e8 un linguaggio fantastico per creare DSL, ma SQL \u00e8 gi\u00e0 di per s\u00e9 un fantastico DSL, e non abbiamo bisogno di un altro. Le S-espressioni sono splendide, ma qui non aggiungono nulla di nuovo. In definitiva, otteniamo parentesi per il solo gusto di avere parentesi. Non siete d'accordo? Allora aspettate quel momento in cui l'astrazione sul DB inizia a perdere colpi e iniziate a combattere con la funzione. (raw-sql)<\/em><\/p>\n
E cosa fare? Lasciamo SQL come SQL \u2014 un file per ogni query:<\/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 leggi 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 chiamata `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', si ottiene:<\/p>\n