{"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":"Eksperienca \u00abDatabase as Code\u00bb","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Eksperienca<\/p>\n

<\/p>\n

SQL, \u00e7far\u00eb mund t\u00eb jet\u00eb m\u00eb e thjesht\u00eb? \u00c7do prej nesh mund t\u00eb shkruaj\u00eb nj\u00eb k\u00ebrkes\u00eb t\u00eb thjesht\u00eb \u2014 shkruajm\u00eb select<\/em><\/strong>, rendisim kolonat e nevojshme, pastaj from<\/em><\/strong>, emri i tabel\u00ebs, pak kushte n\u00eb where<\/em><\/strong> dhe gjith\u00e7ka \u2014 t\u00eb dh\u00ebna t\u00eb dobishme kemi n\u00eb xhep, ndonj\u00ebher\u00eb (gati) pa marr\u00eb parasysh se cila DBMS \u00ebsht\u00eb n\u00eb sfond (apo ndoshta nuk \u00ebsht\u00eb nj\u00eb DBMS fare<\/a><\/noindex>). Si n\u00eb rezultat, puna me pothuajse \u00e7do burim t\u00eb dh\u00ebnash (relacional dhe jo vet\u00ebm) mund t\u00eb shqyrtohet nga k\u00ebndv\u00ebshtrimi i kodit t\u00eb zakonsh\u00ebm (me t\u00eb gjitha pasojat \u2014 kontrolli i versioneve, rishikimi i kodit, analiza statike, testet automatike dhe gjith\u00eb kjo). Kjo nuk i p\u00ebrket vet\u00ebm t\u00eb dh\u00ebnave vet\u00eb, skemave dhe migroveve, por n\u00eb p\u00ebrgjith\u00ebsi t\u00eb gjith\u00eb aktiviteteve t\u00eb depozitimit. N\u00eb k\u00ebt\u00eb artikull do t\u00eb flasim p\u00ebr detyrat dhe problemet e p\u00ebrditshme q\u00eb lidhen me pun\u00ebn me baza t\u00eb ndryshme t\u00eb dh\u00ebnash n\u00ebn lentet e \"database as code\".<\/p>\n

<\/p>\n

Dhe do t\u00eb fillojm\u00eb me ORM<\/a><\/noindex>. Betejat e para t\u00eb llojit \"SQL vs ORM\" u vun\u00eb re q\u00eb n\u00eb Rusin\u00eb para Pjetrit<\/a><\/noindex>.<\/p>\n

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

Mapimi objekt-relacional<\/h5>\n

<\/p>\n

P\u00ebrkrah\u00ebsit e ORM zakonisht e 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 i pun\u00ebs me DB (dhe shpesh 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 mbushur me annotime t\u00eb zgjuara, nd\u00ebrsa diku pas skenave ORM-i trim gjeneron dhe ekzekuton ton me ndonj\u00eb SQL. N\u00eb fakt, zhvilluesit po p\u00ebrpiqen n\u00eb \u00e7do m\u00ebnyr\u00eb t\u00eb t\u00ebrheqin veten nga baza e t\u00eb dh\u00ebnave t\u00eb tyre me kilometra abstraksionesh, q\u00eb flet p\u00ebr nj\u00eb far\u00eb \"SQL e urrejtur\"<\/a><\/noindex>.<\/p>\n
<\/p>\n
N\u00eb an\u00ebn tjet\u00ebr t\u00eb barricad\u00ebs, mb\u00ebshtet\u00ebsit e SQL-it t\u00eb past\u00ebr \"handmade\" n\u00ebnvizojn\u00eb mund\u00ebsin\u00eb p\u00ebr t\u00eb nxjerr\u00eb maksimumin nga DBMS-i i tyre pa pengesa dhe abstraksione t\u00eb dor\u00ebs s\u00eb tret\u00eb. Kjo \u00e7on n\u00eb shfaqjen e projekteve \"data-centric\" ku baza e t\u00eb dh\u00ebnave trajtohet nga individ\u00eb t\u00eb trajnuar specifikisht (ata jan\u00eb \"bazaist\u00eb\", \"bazovik\u00eb\", \"bazd\u00ebnj\u00ebs\" etj.), nd\u00ebrsa zhvilluesit vet\u00ebm duhet t\u00eb \"t\u00ebrheqin\" pamjet dhe procedurat e ruajtura, pa hyr\u00eb n\u00eb detaje.<\/p>\n
<\/p>\n
E \u00e7far\u00eb n\u00ebse marrim m\u00eb t\u00eb mir\u00ebn nga t\u00eb dy bot\u00ebt? Si \u00ebsht\u00eb b\u00ebr\u00eb n\u00eb mjetin e mrekulluesh\u00ebm me nj\u00eb em\u00ebr q\u00eb afirmon jet\u00ebn Yesql<\/a><\/noindex>. Do t'ju jap disa fjal\u00eb nga koncepti i p\u00ebrgjithsh\u00ebm n\u00eb p\u00ebrkthimin tim t\u00eb lir\u00eb, nd\u00ebrsa mund t\u00eb njihet m\u00eb n\u00eb detaje. k\u00ebtu<\/a><\/noindex>.<\/p>\n
<\/p>\n
Clojure \u00ebsht\u00eb nj\u00eb gjuh\u00eb e shk\u00eblqyer p\u00ebr krijimin e DSL-ve, por SQL \u00ebsht\u00eb vet\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 ato nuk sjellin asgj\u00eb t\u00eb re. N\u00eb fund, marrim kllapa p\u00ebr kllapa. Nuk jeni dakord? At\u00ebher\u00eb prisni q\u00eb abstraksioni mbi DB-n\u00eb t\u00eb ket\u00eb nj\u00eb rrjedhje dhe do t\u00eb filloni luft\u00ebn me funksionin. (raw-sql)<\/em><\/p>\n
Dhe \u00e7far\u00eb duhet t\u00eb b\u00ebjm\u00eb? Le t\u00eb l\u00ebm\u00eb SQL-in si SQL-in e zakonsh\u00ebm \u2014 nj\u00eb skedar p\u00ebr nj\u00eb k\u00ebrkes\u00eb:<\/p><\/blockquote>\n
<\/p>\n
-- emri: p\u00ebrdoruesit sipas vendit\nselect *\n  from users\n where country_code = :country_code<\/code><\/pre>\n
<\/p>\n
\u2026 dhe pastaj lexoni k\u00ebt\u00eb skedar, duke e shnd\u00ebrruar at\u00eb 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 ndjekur parimin \"SQL ve\u00e7mas, Clojure ve\u00e7mas\", ju fitoni:<\/p>\n