{"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\/hu\/blog\/administrirovanie\/database-as-sode-experience","title":{"rendered":"\u201eAdatb\u00e1zis mint K\u00f3d\u201d tapasztalat","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"\u201eAdatb\u00e1zis<\/p>\n

<\/p>\n

SQL, mi lehetne egyszer\u0171bb? Mindannyian tudunk \u00edrni egy egyszer\u0171 lek\u00e9rdez\u00e9st \u2013 be\u00edrjuk select<\/em><\/strong>, felsoroljuk a sz\u00fcks\u00e9ges oszlopokat, majd a<\/em><\/strong>, a t\u00e1bl\u00e1zat nev\u00e9t, egy kis felt\u00e9teleket a where<\/em><\/strong> \u00e9s ennyi \u2013 a hasznos adatok a zseb\u00fcnkben vannak, r\u00e1ad\u00e1sul (szinte) f\u00fcggetlen\u00fcl att\u00f3l, hogy \u00e9ppen melyik DBMS m\u0171k\u00f6dik a h\u00e1tt\u00e9rben (vagy tal\u00e1n nem is DBMS<\/a><\/noindex>). Ennek eredm\u00e9nyek\u00e9nt szinte b\u00e1rmilyen adatforr\u00e1st (rel\u00e1ci\u00f3sat \u00e9s nem annyira) a szok\u00e1sos k\u00f3d szempontj\u00e1b\u00f3l lehet megk\u00f6zel\u00edteni (minden k\u00f6vetkezm\u00e9nnyel \u2013 verzi\u00f3kezel\u00e9s, k\u00f3dellen\u0151rz\u00e9s, statikus elemz\u00e9s, automatikus tesztek \u00e9s \u00edgy tov\u00e1bb). \u00c9s ez nemcsak az adatokra, s\u00e9m\u00e1kra \u00e9s migr\u00e1ci\u00f3kra vonatkozik, hanem a t\u00e1rol\u00f3 \u00e9let\u00e9nek minden aspektus\u00e1ra. Ebben a cikkben a \u201edatabase as code\u201d keretein bel\u00fcl a mindennapi feladatokr\u00f3l \u00e9s probl\u00e9m\u00e1kr\u00f3l fogunk besz\u00e9lni k\u00fcl\u00f6nb\u00f6z\u0151 adatb\u00e1zisokkal kapcsolatban.<\/p>\n

<\/p>\n

\u00c9s kezdj\u00fcnk az ORM<\/a><\/noindex>. Az \u201eSQL vs ORM\u201d t\u00edpus\u00fa els\u0151 csat\u00e1k m\u00e1r kor\u00e1bban \u00e9szlelhet\u0151k voltak pre-Petrine Oroszorsz\u00e1gban<\/a><\/noindex>.<\/p>\n

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

Objektum-rel\u00e1ci\u00f3s lek\u00e9pez\u00e9s<\/h5>\n

<\/p>\n

Az ORM h\u00edvei hagyom\u00e1nyosan \u00e9rt\u00e9kelik a fejleszt\u00e9s sebess\u00e9g\u00e9t \u00e9s egyszer\u0171s\u00e9g\u00e9t, a DBMS-f\u00fcggetlens\u00e9get \u00e9s a k\u00f3d tisztas\u00e1g\u00e1t. Sz\u00e1mosunk sz\u00e1m\u00e1ra a DB-vel val\u00f3 munka k\u00f3dja (\u00e9s sok esetben maga az adatb\u00e1zis is)<\/p>\n

<\/p>\n

\u00e1ltal\u00e1ban \u00edgy n\u00e9z ki…<\/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
A modell tele van okos annot\u00e1ci\u00f3kkal, \u00e9s valahol a h\u00e1tt\u00e9rben a h\u0151sies ORM tonn\u00e1nyi SQL-k\u00f3dot gener\u00e1l \u00e9s futtat. \u00c9rdemes megjegyezni, hogy a fejleszt\u0151k mindent elk\u00f6vetnek, hogy kilom\u00e9terekkel t\u00e1vol tarts\u00e1k magukat az adatb\u00e1zist\u00f3l, ami bizonyos \"SQL gy\u0171l\u00f6let\"<\/a><\/noindex>.<\/p>\n
<\/p>\n
A barik\u00e1d m\u00e1sik oldal\u00e1n a tiszta \"handmade\"-SQL h\u00edvei hangs\u00falyozz\u00e1k, hogy minden cseppet ki lehet pr\u00e9selni az adatb\u00e1zisb\u00f3l tov\u00e1bbi r\u00e9tegek \u00e9s absztrakci\u00f3k n\u00e9lk\u00fcl. Ennek eredm\u00e9nyek\u00e9nt \"data-centric\" projektek sz\u00fcletnek, ahol a b\u00e1zissal kifejezetten k\u00e9pzett emberek foglalkoznak (\u0151k a \"b\u00e1sziak\", \u0151k a \"b\u00e1zovik\", \u0151k a \"b\u00e1zd\u00e9nysikkel\" stb.), m\u00edg a fejleszt\u0151knek csak annyi marad, hogy<\/p>\n
<\/p>\n
De mi van, ha a k\u00e9t vil\u00e1g legjobbjait \u00f6tv\u00f6zz\u00fck? Ahogyan azt a csod\u00e1latos eszk\u00f6z teszi, amelynek \u00e9letes\u00edt\u0151 nev\u00e9n Yesql<\/a><\/noindex>. Bemutatok p\u00e1r sor\u00e1t a koncepci\u00f3r\u00f3l szabad ford\u00edt\u00e1somban, egy\u00e9b r\u00e9szleteket pedig ott tal\u00e1lhatunk. itt<\/a><\/noindex>.<\/p>\n
<\/p>\n
A Clojure egy nagyszer\u0171 nyelv DSL-ek kialak\u00edt\u00e1s\u00e1hoz, de a SQL \u00f6n\u00e1ll\u00f3an is egy remek DSL, \u00e9s nem sz\u00fcks\u00e9ges m\u00e9g egy. Az S-kifejez\u00e9sek csod\u00e1latosak, de itt nem adnak semmi \u00fajat. V\u00e9g\u00fcl kapunk z\u00e1r\u00f3jeleket z\u00e1r\u00f3jelek\u00e9rt. Nem \u00e9rt egyet? Akkor v\u00e1rja meg, am\u00edg az adatb\u00e1zis f\u00f6l\u00f6tti absztrakci\u00f3 elkezd folyni, \u00e9s \u00d6n elkezdi a harcot a funkci\u00f3val. (raw-sql)<\/em><\/p>\n
Mit tegy\u00fcnk? Hagyjuk, hogy a SQL sima SQL maradjon \u2013 egy f\u00e1jl egy lek\u00e9rdez\u00e9shez:<\/p><\/blockquote>\n
<\/p>\n
-- n\u00e9v: users-by-country\nselect *\n  from users\n where country_code = :country_code<\/code><\/pre>\n
<\/p>\n
\u2026 majd olvassa el ezt a f\u00e1jlt, \u00e9s alak\u00edtsa \u00e1t egy sima Clojure funkci\u00f3v\u00e1:<\/p><\/blockquote>\n
<\/p>\n
(defqueries \"some\/where\/users_by_country.sql\"\n   {:connection db-spec})\n\n;;; L\u00e9trej\u00f6tt egy `users-by-country` nev\u0171 f\u00fcggv\u00e9ny.\n;;; Haszn\u00e1ljuk:\n(users-by-country {:country_code \"GB\"})\n;=> ({:name \"Kris\" :country_code \"GB\" ...} ...)<\/code><\/pre>\n
<\/p>\n
A \u201eSQL k\u00fcl\u00f6n, Clojure k\u00fcl\u00f6n\u201d elv\u00e9t k\u00f6vetve kapja:<\/p>\n