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

\"Do\u015bwiadczenie<\/p>\n

<\/p>\n

SQL, co mo\u017ce by\u0107 prostszego? Ka\u017cdy z nas mo\u017ce napisa\u0107 prosty zapytanie \u2014 wpisujemy select<\/em><\/strong>, wymieniamy potrzebne kolumny, potem od<\/em><\/strong>, nazw\u0119 tabeli, troch\u0119 warunk\u00f3w w gdzie<\/em><\/strong> i to wszystko \u2014 przydatne dane mamy w kieszeni, niezale\u017cnie od tego, jaka baza danych jest aktualnie u\u017cywana (a mo\u017ce i wcale nie baza danych<\/a><\/noindex>). W rezultacie, prac\u0119 z praktycznie ka\u017cdym \u017ar\u00f3d\u0142em danych (relacyjnym i nie tylko) mo\u017cna rozpatrywa\u0107 z perspektywy zwyk\u0142ego kodu (ze wszystkimi tego konsekwencjami \u2014 kontrola wersji, przegl\u0105d kodu, analiza statyczna, testy automatyczne i tym podobne). Dotyczy to nie tylko samych danych, schemat\u00f3w i migracji, ale ca\u0142ej dzia\u0142alno\u015bci magazynu. W tym artykule om\u00f3wimy codzienne zadania i problemy zwi\u0105zane z r\u00f3\u017cnymi bazami danych w kontek\u015bcie \u201ebazy danych jako kodu\u201d.<\/p>\n

<\/p>\n

Zaczniemy od ORM<\/a><\/noindex>. Pierwsze bitwy typu \u201eSQL kontra ORM\u201d zauwa\u017cono ju\u017c w przedpotopowej Rosji<\/a><\/noindex>.<\/p>\n

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

Mapowanie obiektowo-relacyjne<\/h5>\n

<\/p>\n

Zwolennicy ORM tradycyjnie ceni\u0105 szybko\u015b\u0107 i prostot\u0119 tworzenia, niezale\u017cno\u015b\u0107 od bazy danych oraz czysto\u015b\u0107 kodu. Dla wielu z nas kod pracy z baz\u0105 danych (a cz\u0119sto i sama baza danych)<\/p>\n

<\/p>\n

zwykle wygl\u0105da to mniej wi\u0119cej tak\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
Model jest obci\u0105\u017cony m\u0105drymi adnotacjami, a gdzie\u015b w tle dzielny ORM generuje i wykonuje tony jakiego\u015b kodu SQL. Swoj\u0105 drog\u0105, programi\u015bci za wszelk\u0105 cen\u0119 staraj\u0105 si\u0119 oddzieli\u0107 swoje bazy danych od siebie, tworz\u0105c kilometry abstrakcji, co \u015bwiadczy o pewnej \"Nienawi\u015b\u0107 do SQL\"<\/a><\/noindex>.<\/p>\n
<\/p>\n
Po drugiej stronie barykady zwolennicy czystego \"handmade\"-SQL podkre\u015blaj\u0105 mo\u017cliwo\u015b\u0107 wydobycia maksimum z w\u0142asnej bazy danych bez dodatkowych warstw i abstrakcji. W efekcie powstaj\u0105 projekty \u201edata-centric\u201d, w kt\u00f3rych baz\u0105 zajmuj\u0105 si\u0119 specjalnie przeszkolone osoby (zwane \u201ebazistami\u201d, \u201ebazowikami\u201d, \u201ebazd\u0119nikami\u201d itd.), a programi\u015bci tylko \u201ewyci\u0105gaj\u0105\u201d gotowe widoki i procedury, nie wnikaj\u0105c w szczeg\u00f3\u0142y.<\/p>\n
<\/p>\n
A co je\u015bli we\u017amiemy to, co najlepsze z dw\u00f3ch \u015bwiat\u00f3w? Jak to jest zrealizowane w wspania\u0142ym narz\u0119dziu o afirmatywnym tytule Yesql<\/a><\/noindex>. Przytocz\u0119 kilka zda\u0144 z og\u00f3lnej koncepcji w moim swobodnym t\u0142umaczeniu, a bardziej szczeg\u00f3\u0142owo z ni\u0105 mo\u017cna si\u0119 zapozna\u0107 tutaj<\/a><\/noindex>.<\/p>\n
<\/p>\n
Clojure to \u015bwietny j\u0119zyk do tworzenia DSL, jednak SQL sam w sobie jest ju\u017c \u015bwietnym DSL, i nie potrzebujemy kolejnego. Wyra\u017cenia S s\u0105 pi\u0119kne, ale tutaj nie wnosz\u0105 nic nowego. Ostatecznie otrzymujemy nawiasy dla nawias\u00f3w. Nie zgadzasz si\u0119? W takim razie poczekaj, a\u017c abstrahacja nad baz\u0105 danych zacznie przecieka\u0107, a ty zaczniesz walk\u0119 z funkcj\u0105. (raw-sql)<\/em><\/p>\n
I co robi\u0107? Zostawmy SQL jako zwyk\u0142y SQL \u2014 jeden plik na jeden zapytanie:<\/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 a nast\u0119pnie przeczytaj ten plik, przekszta\u0142caj\u0105c go w zwyk\u0142\u0105 funkcj\u0119 Clojure:<\/p><\/blockquote>\n
<\/p>\n
(defqueries \"some\/where\/users_by_country.sql\"\n   {:connection db-spec})\n\n;;; Stworzono funkcj\u0119 o nazwie `users-by-country`.\n;;; U\u017cyjmy jej:\n(users-by-country {:country_code \"GB\"})\n;=> ({:name \"Kris\" :country_code \"GB\" ...} ...)<\/code><\/pre>\n
<\/p>\n
Przestrzegaj\u0105c zasady \"SQL osobno, Clojure osobno\", otrzymujesz:<\/p>\n