{"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\/et\/blog\/administrirovanie\/database-as-sode-experience","title":{"rendered":"\u201eAndmebaas kui kood\u201c kogemus","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"\u201eAndmebaas<\/p>\n

<\/p>\n

SQL, mis v\u00f5iks olla lihtsam? Iga\u00fchel meist on v\u00f5imalik kirjutada lihtne p\u00e4ring \u2014 kirjutame select<\/em><\/strong>, loetleme vajalikud veerud, siis from<\/em><\/strong>, tabeli nime, paar tingimust where<\/em><\/strong> ja k\u00f5ik \u2014 kasulikud andmed on meil taskus, peaaegu s\u00f5ltumata sellest, milline andmebaas praegu t\u00f6\u00f6tamas on (v\u00f5i ei ole see \u00fcldse andmebaas<\/a><\/noindex>). Tulemuseks saab mistahes andmeallika (suhteline v\u00f5i mitte) t\u00f6\u00f6d vaadelda kui tavalist koodi (k\u00f5ikide sellele j\u00e4rgneva \u2014 versioonihalduse, koodikontrolli, staatilise anal\u00fc\u00fcsi, automaatkatsetuste ja muu sarnasega). Ja see puudutab mitte ainult andmeid, skeeme ja migreerimist, vaid kogu talletamise elu. Selles artiklis r\u00e4\u00e4gime igap\u00e4evastest \u00fclesannetest ja probleemidest, mis on seotud erinevate andmebaasidega, silmas pidades<\/p>\n

<\/p>\n

Ja alustame otse ORM<\/a><\/noindex>. Esimesed lahingud stiilis enne Peeter I<\/a><\/noindex>.<\/p>\n

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

Objekti-relatsiooniline kaardistamine<\/h5>\n

<\/p>\n

ORM-i pooldajad hindavad traditsiooniliselt arenduse kiirust ja lihtsust, s\u00f5ltumatust andmebaasidest ning koodi puhtust. Paljude jaoks meie seas n\u00e4eb andmebaasiga t\u00f6\u00f6tamise kood (ja sageli ka sama andmebaas)<\/p>\n

<\/p>\n

n\u00e4eb tavaliselt v\u00e4lja umbes nii\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
Mudel on kaunistatud nutikate annotatsioonidega, ja kusagil lava taga genereerib ja k\u00e4ivitab vapper ORM tonnide viisi mingit SQL-koodi. \u00dctlemata selgelt, arendajad p\u00fc\u00fcavad igal juhul t\u00f5kestada ennast oma andmebaasi eest kilomeetrite kaupa abstraktsioone, mis viitab teatud \"SQL-i vihkamine\"<\/a><\/noindex>.<\/p>\n
<\/p>\n
Teisest k\u00fcljest m\u00e4rkavad puhta \"handmade\"-SQL-i toetajad v\u00f5imalust oma andmebaasist maksimaalselt v\u00e4lja pigistada ilma lisakihtide ja abstraheeringuteta. Tulemuseks on \u201eandmep\u00f5hised\u201c projektid, kus andmete \u00fcle tegelevad spetsiaalselt koolitatud inimesed (nemad on \"andmebaasi spetsialistid\", \"andmebaasi arendajad\", \"andmebaasi t\u00f6\u00f6hobused\" jne), ja arendajatele j\u00e4\u00e4b vaid valmistehtud vaadete ja salvestatud protseduuride \u201ev\u00e4ljat\u00f5mbamine\u201c, ilmaj\u00e4tmine detailidesse s\u00fc\u00fcvimisest.<\/p>\n
<\/p>\n
Aga mis kui v\u00f5tta parem osa kahest maailmast? Kuidas seda on tehtud imelises t\u00f6\u00f6riistas, millel on eluj\u00f5uline nimi Yesql<\/a><\/noindex>. T\u00f5in v\u00e4lja paar rida \u00fcldkonseptsioonist minu vabalt t\u00f5lgitud versioonis, kuid selle kohtadega saab tutvuda p\u00f5hjalikumalt siin<\/a><\/noindex>.<\/p>\n
<\/p>\n
Clojure on suurep\u00e4rane keel DSL-ide loomiseks, kuid SQL iseenesest on juba hea DSL, ja me ei vaja veel \u00fchte. S-i avaldised on imelised, kuid siin ei lisata need midagi uut. Tulemuseks on sulud ainult sulude p\u00e4rast. Kui ei n\u00f5ustu? Siis oodake hetke, kui abstraheerimine andmebaasi \u00fcle muutub lekivaks, ja te alustate t\u00fcli funktsiooni... (raw-sql)<\/em><\/p>\n
Ja mida teha? J\u00e4tame SQL lihtsalt tavaliseks SQL-iks \u2014 \u00fcks fail \u00fche p\u00e4ringu jaoks:<\/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 ja seej\u00e4rel loe see fail ning muuda see tavaliseks Clojure funktsiooniks:<\/p><\/blockquote>\n
<\/p>\n
(defqueries \"some\/where\/users_by_country.sql\"\n   {:connection db-spec})\n\n;;; Funksiooni nimega `users-by-country` on loodud.\n;;; Kasutame seda:\n(users-by-country {:country_code \"GB\"})\n;=> ({:name \"Kris\" :country_code \"GB\" ...} ...)<\/code><\/pre>\n
<\/p>\n
J\u00e4rgides printsiipi \"SQL eraldi, Clojure eraldi\", saate:<\/p>\n