{"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":"\u00abAndmed kui kood\u00bb kogemus","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"\u00abAndmed<\/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, seej\u00e4rel from<\/em><\/strong>, tabeli nimi, natuke tingimusi where<\/em><\/strong> ja k\u00f5ik \u2014 kasulikud andmed on meie k\u00e4sutuses, (peaaegu) s\u00f5ltumatult sellest, millisest andmebaasis\u00fcsteemist me r\u00e4\u00e4gime (v\u00f5ib-olla see ei ole isegi ande s\u00fcsteem)<\/a><\/noindex>). Seet\u00f5ttu saab praktiliselt iga andmeallikaga (suhtelise ja muu) t\u00f6\u00f6tlust k\u00e4sitleda nagu tavalist koodi (k\u00f5ikide tagaj\u00e4rgedega - versioonihaldus, koodi \u00fclevaatus, staatiline anal\u00fc\u00fcs, automaattestid ja k\u00f5ik see muu). See kehtib mitte ainult andmete, skeemide ja migratsioonide, vaid ka kogu teabehoidmise igap\u00e4evaelu kohta. Selles artiklis r\u00e4\u00e4gime igap\u00e4evastest \u00fclesannetest ja probleemidest, millega silmitsi seisavad erinevad andmebaasid, l\u00e4henedes "andmebaas koodina" temaatikale.<\/p>\n

<\/p>\n

Ja alustame otse ORM<\/a><\/noindex>. Esimesed lahingud stiilis "SQL vs ORM" m\u00e4rgati juba eelk\u00e4ija Venemaal<\/a><\/noindex>.<\/p>\n

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

Objekt-relatsiooniline kaardistamine<\/h5>\n

<\/p>\n

ORM-i toetajad hindavad traditsiooniliselt arendamise kiirust ja lihtsust, s\u00f5ltumatust andmebaasis\u00fcsteemist ning koodi puhtust. Paljude jaoks n\u00e4eb andmebaasit\u00f6\u00f6 kood (ja sageli isegi andmebaas ise)<\/p>\n

<\/p>\n

tavaliselt n\u00e4eb 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 varustatud nutikate annotatsioonidega, samal ajal kui hiilgav ORM genereerib ja t\u00e4idab tohutult SQL-koodi. Pealegi p\u00fc\u00fcavad arendajad igasuguste abstraktsioonidega ennast oma andmebaasist eemal hoida, mis viitab teatud "SQL vihkamise"<\/a><\/noindex>.<\/p>\n
<\/p>\n
Teisel pool barikaadi toetajad puhta \"handmade\"-SQL-i osas r\u00f5hutavad v\u00f5imalust oma andmebaasist maksimum v\u00e4lja pigistada ilma lisakihtide ja abstraktsioonideta. Selle tulemusena tekivad \"data-centric\" projektid, kus andmebaasidega tegelevad spetsiaalselt koolitatud inimesed (need on \"basiistid\", \"basiikud\", \"bazi-j\u00e4rjed\" jne), ning arendajatel j\u00e4\u00e4b vaid \"t\u00f5mmata\" valmis vaateid ja salvestatud protseduure, sukeldumata detailidesse.<\/p>\n
<\/p>\n
Aga mis oleks, kui v\u00f5tta parimad omadused kummastki maailmast? Nii on tehtud selles suurep\u00e4rases t\u00f6\u00f6riistas, millel on eluj\u00f5uline nimi Yesql<\/a><\/noindex>. Toodan paar rida \u00fcldisest kontseptsioonist oma vabalt t\u00f5lgituna, aga rohkemate detailidega saab tutvuda siit<\/a><\/noindex>.<\/p>\n
<\/p>\n
Clojure on suurep\u00e4rane keel DSL-ide loomiseks, kuid SQL on juba iseenesest \u00e4ge DSL ning me ei vaja \u00fchtegi uut. S-expression\u2019id on kaunid, kuid siin ei lisa need midagi uut. L\u00f5puks saame ainult sulud sulude p\u00e4rast. Ei ole n\u00f5us? Oodake hetke, kui abstraktsioon andmebaasi kohal lekib ja alustate v\u00f5itlust funktsiooniga. (raw-sql)<\/em><\/p>\n
Ja mis siis teha? J\u00e4tame SQL-i tavalise SQL-ina \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 ning seej\u00e4rel lugege see fail ning muundage see tavaliseks Clojure funktsiooniks:<\/p><\/blockquote>\n
<\/p>\n
(defqueries \"some\/where\/users_by_country.sql\"\n   {:connection db-spec})\n\n;;; Funktsioon 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