{"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\/lv\/blog\/administrirovanie\/database-as-sode-experience","title":{"rendered":"\u201eDatu b\u0101ze k\u0101 koda\u201d pieredze","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"\u201eDatu<\/p>\n

<\/p>\n

SQL, kas var b\u016bt vienk\u0101r\u0161\u0101k? Ikviens no mums var uzrakst\u012bt vienk\u0101r\u0161u vaic\u0101jumu \u2014 ierakst\u0101m select<\/em><\/strong>, uzskait\u0101m nepiecie\u0161am\u0101s kolonnas, tad no<\/em><\/strong>, tabulas nosaukumu, nedaudz nosac\u012bjumu sada\u013c\u0101 where<\/em><\/strong> un viss \u2014 noder\u012bgie dati ir m\u016bsu r\u012bc\u012bb\u0101, gandr\u012bz (l\u012bdz\u012bgi) neatkar\u012bgi no t\u0101, k\u0101da datub\u0101ze \u0161obr\u012bd tiek izmantota (un varb\u016bt tas nav visp\u0101r datub\u0101ze<\/a><\/noindex>). Rezult\u0101t\u0101 darbu praktiski ar jebkuru datu avotu (attiec\u012bgo un ne tik \u013coti) var uzskat\u012bt no parasta koda skatpunkta (ar visiem tam sekojo\u0161iem - versiju vad\u012bba, koda rev\u012bzija, statiska anal\u012bze, autom\u0101tiskie testi un taml\u012bdz\u012bgi). Un tas attiecas ne tikai uz datiem, sh\u0113m\u0101m un migr\u0101cij\u0101m, bet visp\u0101r uz visu glab\u0101tuves darb\u012bbu. \u0160aj\u0101 rakst\u0101 run\u0101sim par ikdienas uzdevumiem un probl\u0113m\u0101m, str\u0101d\u0101jot ar da\u017e\u0101d\u0101m DB, koncentr\u0113joties uz \"database as code\".<\/p>\n

<\/p>\n

Un s\u0101ksim tie\u0161i ar ORM<\/a><\/noindex>. Pirmie \"SQL vs ORM\" c\u012b\u0146as tika nov\u0113rotas jau pirms P\u0113terburgas<\/a><\/noindex>.<\/p>\n

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

Objektu-rel\u0101ciju kart\u0113\u0161ana<\/h5>\n

<\/p>\n

ORM atbalst\u012bt\u0101ji tradicion\u0101li nov\u0113rt\u0113 izstr\u0101des \u0101trumu un vienk\u0101r\u0161\u012bbu, neatkar\u012bbu no datub\u0101zes, un koda t\u012br\u012bbu. Daudziem no mums datu apstr\u0101des kods (un bie\u017ei ar\u012b pati datub\u0101ze)<\/p>\n

<\/p>\n

parasti izskat\u0101s apm\u0113ram t\u0101\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
Modelis ir piepild\u012bts ar gudr\u0101m anot\u0101cij\u0101m, un kaut kur aiz ainas varon\u012bgais ORM \u0123ener\u0113 un izpilda tonnas k\u0101da SQL koda. Starp citu, izstr\u0101d\u0101t\u0101ji visiem sp\u0113kiem cen\u0161as atdal\u012bties no savas datub\u0101zes ar kilometriem abstrakciju, kas liecina par zin\u0101mu \"SQL naida\"<\/a><\/noindex>.<\/p>\n
<\/p>\n
Otr\u0101 pus\u0113 barik\u0101d\u0113m t\u012br\u0101 \"handmade\"-SQL piekrit\u0113ji atz\u012bm\u0113 iesp\u0113ju izspiest visu no sava DB bez papildu sl\u0101\u0146iem un abstrakcij\u0101m. Rezult\u0101t\u0101 par\u0101d\u0101s \"data-centric\" projekti, kur ar b\u0101z\u0113m str\u0101d\u0101 speci\u0101li apm\u0101c\u012bti cilv\u0113ki (tie pa\u0161i \"b\u0101zisti\", \"b\u0101zoviki\", \"b\u0101zdiennieki\" utt.), un izstr\u0101d\u0101t\u0101jiem atliek tikai \"zvan\u012bt\" uz gatav\u0101m redz\u0113m un glab\u0101t\u0101m proced\u016br\u0101m, neiedzi\u013cinoties deta\u013c\u0101s.<\/p>\n
<\/p>\n
Bet ko, ja \u0146em to lab\u0101ko no ab\u0101m pasaul\u0113m? K\u0101 tas ir izdar\u012bts lieliskaj\u0101 r\u012bk\u0101 ar dz\u012bvotsp\u0113j\u012bgu nosaukumu Yesql<\/a><\/noindex>. Sniedzu da\u017eus teikumus no visp\u0101r\u0113j\u0101s koncepcijas man\u0101 br\u012bv\u0101 tulkojum\u0101, bet pla\u0161\u0101k ar to var iepaz\u012bties \u0161eit<\/a><\/noindex>.<\/p>\n
<\/p>\n
Clojure ir lieliska valoda DSL veido\u0161anai, bet SQL jau pats par sevi ir lielisks DSL, un mums nevajag v\u0113l vienu. S-izteiksmes ir br\u012bni\u0161\u0137\u012bgas, bet \u0161eit t\u0101s neko jaunu nepievieno. Rezult\u0101t\u0101 m\u0113s ieg\u016bstam p\u0113das tikai t\u0101p\u0113c, ka t\u0101s ir p\u0113das. Nevienojaties? Tad gaidiet br\u012bdi, kad abstrakcija p\u0101r DB s\u0101ks pl\u016bst, un j\u016bs uzs\u0101ksiet c\u012b\u0146u ar funkciju (raw-sql)<\/em><\/p>\n
Un ko dar\u012bt? Atst\u0101sim SQL parastu SQL \u2014 viens fails uz vienu piepras\u012bjumu:<\/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 un p\u0113c tam izlasiet \u0161o failu, p\u0101rv\u0113r\u0161ot to par parastu Clojure funkciju:<\/p><\/blockquote>\n
<\/p>\n
(defqueries \"some\/where\/users_by_country.sql\"\n   {:connection db-spec})\n\n;;; Funkcijai ar nosaukumu `users-by-country` ir izveidota.\n;;; Izmantojam to:\n(users-by-country {:country_code \"GB\"})\n;=> ({:name \"Kris\" :country_code \"GB\" ...} ...)<\/code><\/pre>\n
<\/p>\n
Iev\u0113rojot principu \"SQL atsevi\u0161\u0137i, Clojure atsevi\u0161\u0137i\", j\u016bs ieg\u016bstat:<\/p>\n