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

\"P\u00ebrvoja<\/p>\n

<\/p>\n

SQL \u2014 \u00e7far\u00eb mund t\u00eb jet\u00eb m\u00eb e thjesht\u00eb? Secili prej nesh mund t\u00eb shkruaj\u00eb nj\u00eb query t\u00eb thjesht\u00eb \u2014 shkruajm\u00eb select<\/em><\/strong>, rendisim kolonat e nevojshme, pastaj from<\/em><\/strong>, emrin e tabel\u00ebs, pak kushte te ku<\/em><\/strong> dhe kaq \u2014 t\u00eb dh\u00ebnat e dobishme i kemi n\u00eb xhep, thuajse pavar\u00ebsisht se cila DBMS fshihet pas sken\u00ebs n\u00eb at\u00eb moment (madje ndoshta as nuk \u00ebsht\u00eb fare DBMS<\/a><\/noindex>). Si p\u00ebrfundim, puna me praktikisht \u00e7do burim t\u00eb dh\u00ebnash (relacional dhe jo shum\u00eb) mund t\u00eb shqyrtohet nga k\u00ebndv\u00ebshtrimi i kodit t\u00eb zakonsh\u00ebm (me t\u00eb gjitha pasojat \u2014 version control, code review, analiza statike, teste automatike dhe gjith\u00eb kjo gj\u00eb). Dhe kjo vlen jo vet\u00ebm p\u00ebr vet\u00eb t\u00eb dh\u00ebnat, skemat dhe migrimet, por p\u00ebr t\u00eb gjith\u00eb jet\u00ebn e depozit\u00ebs. N\u00eb k\u00ebt\u00eb artikull do t\u00eb flasim p\u00ebr detyrat dhe problemet e p\u00ebrditshme t\u00eb pun\u00ebs me baza t\u00eb ndryshme n\u00ebn objektivin e "database as code".<\/p>\n

<\/p>\n

Dhe do ta nisim pik\u00ebrisht me ORM<\/a><\/noindex>. Betejat e para t\u00eb tipit "SQL vs ORM" jan\u00eb v\u00ebn\u00eb re q\u00eb n\u00eb koh\u00eb shum\u00eb t\u00eb hershme<\/a><\/noindex>.<\/p>\n

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

Mapimi objekt-relacional<\/h5>\n

<\/p>\n

Mb\u00ebshtet\u00ebsit e ORM tradicionalisht vler\u00ebsojn\u00eb shpejt\u00ebsin\u00eb dhe thjesht\u00ebsin\u00eb e zhvillimit, pavar\u00ebsin\u00eb nga DBMS dhe past\u00ebrtin\u00eb e kodit. P\u00ebr shum\u00eb prej nesh, kodi p\u00ebr pun\u00ebn me DB (dhe shpesh edhe vet\u00eb DB)<\/p>\n

<\/p>\n

zakonisht duket p\u00ebraf\u00ebrsisht k\u00ebshtu\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
Modeli \u00ebsht\u00eb i mbushur me anotime inteligjente, nd\u00ebrsa diku prapa sken\u00ebs ORM-ja trim\u00ebrore gjeneron dhe ekzekuton tonelata kodi SQL. Meq\u00eb ra fjala, zhvilluesit p\u00ebrpiqen me t\u00eb gjitha forcat t\u00eb distancohen nga DB-ja e tyre p\u00ebrmes kilometrash abstraksionesh, gj\u00eb q\u00eb flet p\u00ebr nj\u00ebfar\u00eb "SQL e urrejtjes"<\/a><\/noindex>.<\/p>\n
<\/p>\n
Nga ana tjet\u00ebr e barricad\u00ebs, mb\u00ebshtet\u00ebsit e "handmade"-SQL-it v\u00ebn\u00eb n\u00eb dukje mund\u00ebsin\u00eb e shfryt\u00ebzimit t\u00eb plot\u00eb t\u00eb struktur\u00ebs s\u00eb tyre t\u00eb t\u00eb dh\u00ebnave pa shtresa dhe abstraksione t\u00eb tjera. Si pasoj\u00eb e k\u00ebsaj shfaqen projekte "data-centric", ku baza merret me njer\u00ebz t\u00eb trajnuar posa\u00e7\u00ebrisht (ata quhen gjithashtu "bazist\u00eb", "bazovik\u00eb", "bazd\u00ebnj\u00ebs" etj.), nd\u00ebrsa zhvilluesit nuk kan\u00eb asgj\u00eb tjet\u00ebr ve\u00e7se t\u00eb q\u00ebndrojn\u00eb t\u00eb lidhur me pamjet dhe procedurat e ruajtura, pa hyr\u00eb n\u00eb detaje.<\/p>\n
<\/p>\n
Po sikur t\u00eb marrim m\u00eb t\u00eb mir\u00ebn nga t\u00eb dy bot\u00ebt? Pik\u00ebrisht si\u00e7 \u00ebsht\u00eb b\u00ebr\u00eb n\u00eb mjetin e shk\u00eblqyer me emrin optimist Yesql<\/a><\/noindex>. Do t\u00eb sjell disa rreshta nga koncepti i p\u00ebrgjithsh\u00ebm n\u00eb p\u00ebrkthimin tim t\u00eb lir\u00eb, nd\u00ebrsa me t\u00eb mund t\u00eb njiheni m\u00eb n\u00eb holl\u00ebsi k\u00ebtu<\/a><\/noindex>.<\/p>\n
<\/p>\n
Clojure \u00ebsht\u00eb nj\u00eb gjuh\u00eb fantastike p\u00ebr t\u00eb krijuar DSL\u2019je, por SQL vet\u00eb \u00ebsht\u00eb nj\u00eb DSL i shk\u00eblqyer, dhe nuk na nevojitet nj\u00eb tjet\u00ebr. S-shprehjet jan\u00eb t\u00eb bukura, por k\u00ebtu nuk sjellin asgj\u00eb t\u00eb re. Rezultati \u00ebsht\u00eb se krijojm\u00eb kllapa p\u00ebr shkakun e kllapave. Nuk e pranon? At\u00ebher\u00eb presim momentin kur abstraksioni mbi baz\u00ebn do t\u00eb lejoj\u00eb rrjedhje, dhe do t\u00eb filloni luft\u00ebn me funksionin (raw-sql)<\/em><\/p>\n
Dhe \u00e7far\u00eb t\u00eb b\u00ebjm\u00eb? Le ta l\u00ebm\u00eb SQL t\u00eb mbetet SQL i zakonsh\u00ebm \u2014 nj\u00eb skedar p\u00ebr \u00e7do k\u00ebrkes\u00eb:<\/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 dhe m\u00eb pas lexoni k\u00ebt\u00eb skedar, duke e kthyer n\u00eb nj\u00eb funksion t\u00eb zakonsh\u00ebm Clojure:<\/p><\/blockquote>\n
<\/p>\n
(defqueries "some\/where\/users_by_country.sql"\n   {:connection db-spec})\n\n;;; Nj\u00eb funksion me emrin `users-by-country` \u00ebsht\u00eb krijuar.\n;;; Le ta p\u00ebrdorim:\n(users-by-country {:country_code "GB"})\n;=> ({:name "Kris" :country_code "GB" ...} ...)<\/code><\/pre>\n
<\/p>\n
Duke e ndjekur parimin "SQL ve\u00e7mas, Clojure ve\u00e7mas", ju merrni:<\/p>\n