{"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\/cs\/blog\/administrirovanie\/database-as-sode-experience","title":{"rendered":"Zku\u0161enost \u201eDatabase as Code\u201c","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Zku\u0161enost<\/p>\n

<\/p>\n

SQL, co m\u016f\u017ee b\u00fdt jednodu\u0161\u0161\u00ed? Ka\u017ed\u00fd z n\u00e1s m\u016f\u017ee napsat jednoduch\u00fd dotaz \u2013 zad\u00e1me select<\/em><\/strong>, uvedeme pot\u0159ebn\u00e9 sloupce, pak from<\/em><\/strong>, jm\u00e9no tabulky, trochu podm\u00ednek v where<\/em><\/strong> a je to \u2013 u\u017eite\u010dn\u00e1 data m\u00e1me v kapse, a to (t\u00e9m\u011b\u0159) nez\u00e1visle na tom, jak\u00e1 S\u0158BD je pr\u00e1v\u011b pod kapotou (nebo to mo\u017en\u00e1 nen\u00ed S\u0158BD v\u016fbec<\/a><\/noindex>). Jako v\u00fdsledek lze na pr\u00e1ci s t\u00e9m\u011b\u0159 jak\u00fdmkoli zdrojem dat (rela\u010dn\u00edm i jin\u00fdm) pohl\u00ed\u017eet jako na b\u011b\u017en\u00fd k\u00f3d (se v\u0161emi d\u016fsledky \u2014 verzov\u00e1n\u00ed, revize k\u00f3du, statick\u00e1 anal\u00fdza, automatizovan\u00e9 testy a tak d\u00e1le). To se t\u00fdk\u00e1 nejen samotn\u00fdch dat, sch\u00e9mat a migrac\u00ed, ale v\u016fbec cel\u00e9 \u010dinnosti \u00falo\u017ei\u0161t\u011b. V tomto \u010dl\u00e1nku se pod\u00edv\u00e1me na ka\u017edodenn\u00ed \u00fakoly a probl\u00e9my p\u0159i pr\u00e1ci s r\u016fzn\u00fdmi datab\u00e1zemi z pohledu \u201edatab\u00e1ze jako k\u00f3d\u201c.<\/p>\n

<\/p>\n

A za\u010dneme hned s ORM<\/a><\/noindex>. Prvn\u00ed bitvy typu \u201eSQL vs ORM\u201c byly zaznamen\u00e1ny ji\u017e v p\u0159edpetrsk\u00e9 Rusko<\/a><\/noindex>.<\/p>\n

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

Objektov\u011b-rela\u010dn\u00ed mapov\u00e1n\u00ed<\/h5>\n

<\/p>\n

Zast\u00e1nci ORM tradi\u010dn\u011b oce\u0148uj\u00ed rychlost a jednoduchost v\u00fdvoje, nez\u00e1vislost na S\u0158BD a \u010distotu k\u00f3du. Pro mnoh\u00e9 z n\u00e1s k\u00f3d pr\u00e1ce s DB (a \u010dasto i samotn\u00e1 DB)<\/p>\n

<\/p>\n

obvykle vypad\u00e1 p\u0159ibli\u017en\u011b 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
Model je obohacen chytr\u00fdmi anotacemi, a n\u011bkde v z\u00e1kulis\u00ed state\u010dn\u00e9 ORM generuje a vykon\u00e1v\u00e1 tuny n\u011bjak\u00e9ho SQL k\u00f3du. Mimochodem, v\u00fdvoj\u00e1\u0159i se sna\u017e\u00ed za ka\u017edou cenu odd\u011blit od sv\u00e9 DB kilometry abstrakc\u00ed, co\u017e sv\u011bd\u010d\u00ed o jist\u00e9 \"SQL nen\u00e1visti\"<\/a><\/noindex>.<\/p>\n
<\/p>\n
Na druh\u00e9 stran\u011b barik\u00e1dy zast\u00e1nci \u010dist\u00e9ho \"handmade\"-SQL zd\u016fraz\u0148uj\u00ed mo\u017enost vyt\u011b\u017eit maximum ze sv\u00e9 DB bez dal\u0161\u00edch vrstev a abstrakc\u00ed. V d\u016fsledku toho vznikaj\u00ed \"data-centric\" projekty, kde se o datab\u00e1ze staraj\u00ed speci\u00e1ln\u011b vy\u0161kolen\u00ed lid\u00e9 (ti, kte\u0159\u00ed se naz\u00fdvaj\u00ed \"datab\u00e1rist\u00e9\", tak\u00e9 \"datab\u00e1z\u00e1ci\", tak\u00e9 \"b\u00e1zov\u00ed pracovn\u00edci\" atd.), a v\u00fdvoj\u00e1\u0159\u016fm z\u016fst\u00e1v\u00e1 pouze \"tahat\" hotov\u00e9 pohledy a ulo\u017een\u00e9 procedury, ani\u017e by se zab\u00fdvali detaily.<\/p>\n
<\/p>\n
A co kdybychom vzali to nejlep\u0161\u00ed z obou sv\u011bt\u016f? Jak je to ud\u011bl\u00e1no ve skv\u011bl\u00e9m n\u00e1stroji s povzbudiv\u00fdm n\u00e1zvem Yesql<\/a><\/noindex>. Uvedu p\u00e1r \u0159\u00e1dk\u016f z obecn\u00e9 koncepce ve sv\u00e9m voln\u00e9m p\u0159ekladu, a podrobn\u011bji se s n\u00ed m\u016f\u017eete sezn\u00e1mit zde<\/a><\/noindex>.<\/p>\n
<\/p>\n
Clojure je skv\u011bl\u00fd jazyk pro vytv\u00e1\u0159en\u00ed DSL, ale SQL u\u017e samo o sob\u011b je \u00fa\u017easn\u00fd DSL, a nepot\u0159ebujeme dal\u0161\u00ed. S-v\u00fdrazy jsou n\u00e1dhern\u00e9, ale zde nic nov\u00e9ho do hry nevn\u00e1\u0161ej\u00ed. Nakonec dost\u00e1v\u00e1me z\u00e1vorky jen pro samotn\u00e9 z\u00e1vorky. Neshodujete se? Pak po\u010dkejte, a\u017e abstrahce nad datab\u00e1z\u00ed za\u010dne selh\u00e1vat, a vy za\u010dne bojovat s funkc\u00ed (raw-sql)<\/em><\/p>\n
A co te\u010f? Poj\u010fme nechat SQL jako oby\u010dejn\u00e9 SQL \u2014 jeden soubor 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 pot\u00e9 si tento soubor p\u0159e\u010dt\u011bte a p\u0159eve\u010fte ho na b\u011b\u017enou funkci v Clojure:<\/p><\/blockquote>\n
<\/p>\n
(defqueries \"some\/where\/users_by_country.sql\"\n   {:connection db-spec})\n\n;;; Byla vytvo\u0159ena funkce s n\u00e1zvem `users-by-country`.\n;;; Pou\u017eijme ji:\n(users-by-country {:country_code \"GB\"})\n;=> ({:name \"Kris\" :country_code \"GB\" ...} ...)<\/code><\/pre>\n
<\/p>\n
Zachov\u00e1n\u00edm principu \"SQL zvl\u00e1\u0161\u0165, Clojure zvl\u00e1\u0161\u0165\" z\u00edsk\u00e1te:<\/p>\n