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

\"Z\u00e1\u017eitok<\/p>\n

<\/p>\n

SQL, \u010do m\u00f4\u017ee by\u0165 jednoduch\u0161ie? Ka\u017ed\u00fd z n\u00e1s m\u00f4\u017ee nap\u00edsa\u0165 jednoduch\u00fd dotaz \u2014 zad\u00e1me select<\/em><\/strong>, vymen\u00favame potrebn\u00e9 st\u013apce, potom z<\/em><\/strong>, n\u00e1zov tabu\u013eky, trochu podmienok v kde<\/em><\/strong> a v\u0161etko \u2014 u\u017e m\u00e1me u\u017eito\u010dn\u00e9 d\u00e1ta v na\u0161ich ruk\u00e1ch, pri\u010dom (takmer) nez\u00e1le\u017e\u00ed na tom, ak\u00fd DBMS sa nach\u00e1dza pod kapotom (alebo to mo\u017eno ani nie je DBMS). V\u00fdsledkom je, \u017ee s ak\u00fdmko\u013evek zdrojom \u00fadajov (rela\u010dn\u00fdm alebo nie) sa d\u00e1 pracova\u0165 z poh\u013eadu be\u017en\u00e9ho k\u00f3du (s v\u0161etk\u00fdm, \u010do z toho vypl\u00fdva \u2014 verzionovanie, rev\u00edzia k\u00f3du, statick\u00e1 anal\u00fdza, automatizovan\u00e9 testy a v\u0161etko toto). A to sa net\u00fdka len samotn\u00fdch d\u00e1t, sch\u00e9m a migr\u00e1ci\u00ed, ale v\u00f4bec celej \u010dinnosti \u00falo\u017eiska. V tomto \u010dl\u00e1nku sa budeme zaobera\u0165 ka\u017edodenn\u00fdmi \u00falohami a probl\u00e9mami pri pr\u00e1ci s r\u00f4znymi DB so zameran\u00edm na \"datab\u00e1zu ako k\u00f3d\".<\/a><\/noindex>). V d\u00f4sledku toho mo\u017eno pracova\u0165 prakticky s ak\u00fdmiko\u013evek zdrojmi \u00fadajov (rela\u010dn\u00fdmi aj nie) z poh\u013eadu be\u017en\u00e9ho k\u00f3du (so v\u0161etk\u00fdm, \u010do k tomu patr\u00ed \u2014 verzionovanie, rev\u00edzia k\u00f3du, statick\u00e1 anal\u00fdza, automatizovan\u00e9 testy a podobne). A to sa t\u00fdka nielen samotn\u00fdch \u00fadajov, sch\u00e9m a migr\u00e1ci\u00ed, ale vlastne celej \u017eivotnosti \u00falo\u017eiska. V tomto \u010dl\u00e1nku sa budeme venova\u0165 ka\u017edodenn\u00fdm \u00faloh\u00e1m a probl\u00e9mom pri pr\u00e1ci s r\u00f4znymi datab\u00e1zami z h\u013eadiska "database as code".<\/p>\n

<\/p>\n

ORM. Prv\u00e9 bitky typu \"SQL vs ORM\" boli zaznamenan\u00e9 u\u017e v<\/a><\/noindex>. Prv\u00e9 bitky typu "SQL vs ORM" boli zaznamenan\u00e9 u\u017e v Objektovo-rela\u010dn\u00e9 mapovanie<\/a><\/noindex>.<\/p>\n

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

Z\u00e1stancovia ORM tradi\u010dne oce\u0148uj\u00fa r\u00fdchlos\u0165 a jednoduchos\u0165 v\u00fdvoja, nez\u00e1vislos\u0165 od DBMS a \u010distotu k\u00f3du. Pre mnoh\u00fdch z n\u00e1s k\u00f3d pr\u00e1ce s DB (a \u010dasto aj samotn\u00e1 DB)<\/h5>\n

<\/p>\n

vyzer\u00e1 zvy\u010dajne pribli\u017ene takto\u2026<\/p>\n

<\/p>\n

zvy\u010dajne vyzer\u00e1 pribli\u017ene takto\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
\"SQL nen\u00e1vis\u0165.\" "SQL nen\u00e1visti"<\/a><\/noindex>.<\/p>\n
<\/p>\n
Na druhej strane barik\u00e1dy pr\u00edvr\u017eenci \u010distej "handmade"-SQL poukazuj\u00fa na mo\u017enos\u0165 vy\u017em\u00fdka\u0165 maximum zo svojej DB bez dodato\u010dn\u00fdch vrstiev a abstrakci\u00ed. V d\u00f4sledku toho vznikaj\u00fa "data-centric" projekty, kde sa datab\u00e1zami zaoberaj\u00fa \u0161peci\u00e1lne vy\u0161kolen\u00ed \u013eudia (tie\u017e naz\u00fdvan\u00ed "datab\u00e1zisti", "datab\u00e1zov\u00ed \u0161pecialisti" a pod.), a v\u00fdvoj\u00e1rom ost\u00e1va len "\u0165aha\u0165" hotov\u00e9 poh\u013eady a ulo\u017een\u00e9 proced\u00fary, ani\u017e by sa zaoberali podrobnos\u0165ami.<\/p>\n
<\/p>\n
Yesql. Uvediem p\u00e1r vet z celkovej koncepcie vo svojom vo\u013enom preklade, a podrobnej\u0161ie sa s \u0148ou m\u00f4\u017eete obozn\u00e1mi\u0165.<\/a><\/noindex>. Uvediem p\u00e1r viet z v\u0161eobecnej koncepcie vo svojom vo\u013enom preklade, a podrobnej\u0161ie sa s \u0148ou m\u00f4\u017eete obozn\u00e1mi\u0165 tu<\/a><\/noindex>.<\/p>\n
<\/p>\n
Clojure je skvel\u00fd jazyk na vytv\u00e1ranie DSL, ale SQL je u\u017e s\u00e1m osebe skvel\u00fd DSL, a nepotrebujeme \u010fal\u0161\u00ed. S-v\u00fdrazy s\u00fa \u00fa\u017easn\u00e9, ale tu neprin\u00e1\u0161aj\u00fa ni\u010d nov\u00e9. Nakoniec dostaneme z\u00e1tvorky len pre z\u00e1tvorky. Nes\u00fahlas\u00edte? Potom si po\u010dkajte, kedy abstrakcia nad datab\u00e1zou za\u010dne unika\u0165 a vy za\u010dnete bojova\u0165 s funkciou. (raw-sql)<\/em><\/p>\n
A \u010do robi\u0165? Po\u010fme necha\u0165 SQL oby\u010dajn\u00fdm SQL \u2014 jeden s\u00fabor na jeden dotaz:<\/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 potom si pre\u010d\u00edtajte tento s\u00fabor a preme\u0148te ho na oby\u010dajn\u00fa Clojure funkciu:<\/p><\/blockquote>\n
<\/p>\n
(defqueries "some\/where\/users_by_country.sql"\n   {:connection db-spec})\n\n;;; Bola vytvoren\u00e1 funkcia s n\u00e1zvom `users-by-country`.\n;;; Po\u010fme ju pou\u017ei\u0165:\n(users-by-country {:country_code "GB"})\n;=> ({:name "Kris" :country_code "GB" ...} ...)<\/code><\/pre>\n
<\/p>\n
Dodr\u017eiavan\u00edm princ\u00edpu "SQL oddelene, Clojure oddelene" z\u00edskate:<\/p>\n