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

\"L'Exp\u00e9rience<\/p>\n

<\/p>\n

SQL, que peut-il y avoir de plus simple ? Chacun d'entre nous peut \u00e9crire une requ\u00eate basique \u2014 nous tapons select<\/em><\/strong>, \u00e9num\u00e9rons les colonnes n\u00e9cessaires, puis from<\/em><\/strong>, le nom de la table, quelques conditions dans o\u00f9<\/em><\/strong> et voil\u00e0 \u2014 les donn\u00e9es utiles sont \u00e0 port\u00e9e de main, et ce, presque ind\u00e9pendamment de la base de donn\u00e9es utilis\u00e9e en dessous (ou peut-\u00eatre m\u00eame pas une base de donn\u00e9es du tout<\/a><\/noindex>). En cons\u00e9quence, il est possible d'examiner le travail avec pratiquement n'importe quelle source de donn\u00e9es (relationnelle ou non) sous l'angle d'un simple code (avec toutes les implications \u2014 contr\u00f4le de version, relecture de code, analyse statique, tests automatis\u00e9s, et tout cela). Et cela concerne non seulement les donn\u00e9es elles-m\u00eames, les sch\u00e9mas et les migrations, mais en fait toute l'activit\u00e9 du stockage. Dans cet article, nous parlerons des t\u00e2ches quotidiennes et des probl\u00e8mes li\u00e9s \u00e0 l'utilisation de diff\u00e9rentes bases de donn\u00e9es sous l'angle de "database as code".<\/p>\n

<\/p>\n

Et commen\u00e7ons par ORM<\/a><\/noindex>. Les premiers affrontements du type "SQL contre ORM" ont \u00e9t\u00e9 observ\u00e9s d\u00e8s la Russie pr\u00e9-p\u00e9troli\u00e8re<\/a><\/noindex>.<\/p>\n

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

Mapping objet-relationnel<\/h5>\n

<\/p>\n

Les partisans de l'ORM appr\u00e9cient traditionnellement la rapidit\u00e9 et la simplicit\u00e9 de d\u00e9veloppement, l'ind\u00e9pendance vis-\u00e0-vis de la base de donn\u00e9es et la propret\u00e9 du code. Pour beaucoup d'entre nous, le code de travail avec la base de donn\u00e9es (et souvent la base de donn\u00e9es elle-m\u00eame)<\/p>\n

<\/p>\n

ressemble g\u00e9n\u00e9ralement \u00e0 peu pr\u00e8s \u00e0 ceci\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
Le mod\u00e8le est agr\u00e9ment\u00e9 d'annotations intelligentes, tandis qu'en coulisses, le valeureux ORM g\u00e9n\u00e8re et ex\u00e9cute des tonnes de code SQL. \u00c0 propos, les d\u00e9veloppeurs tentent par tous les moyens de se distancer de leur base de donn\u00e9es avec des kilom\u00e8tres d'abstractions, ce qui indique une certaine "SQL de la haine"<\/a><\/noindex>.<\/p>\n
<\/p>\n
De l'autre c\u00f4t\u00e9 des barricades, les partisans du "handmade"-SQL soulignent la possibilit\u00e9 de tirer le meilleur parti de leur SGBD sans couches et abstractions suppl\u00e9mentaires. Ce qui donne naissance \u00e0 des projets "data-centric" o\u00f9 la base de donn\u00e9es est g\u00e9r\u00e9e par des personnes sp\u00e9cialement form\u00e9es (elles sont aussi appel\u00e9es "data specialists", "DBAs", et ainsi de suite), et les d\u00e9veloppeurs n'ont qu'\u00e0 "tirer" des vues et des proc\u00e9dures stock\u00e9es pr\u00eates \u00e0 l'emploi, sans entrer dans les d\u00e9tails.<\/p>\n
<\/p>\n
Que se passerait-il si nous prenions le meilleur des deux mondes ? Comme c'est le cas dans cet outil remarquable au nom affermissant Yesql<\/a><\/noindex>. Je vais donner quelques lignes de la conception g\u00e9n\u00e9rale dans ma traduction libre, et vous pouvez vous familiariser plus en d\u00e9tail avec cela. ici<\/a><\/noindex>.<\/p>\n
<\/p>\n
Clojure est un langage g\u00e9nial pour cr\u00e9er des DSL, mais SQL est d\u00e9j\u00e0 en soi un excellent DSL, et nous n'avons pas besoin d'un autre. Les expressions S sont super, mais ici elles n'apportent rien de nouveau. Au final, cela revient \u00e0 avoir des parenth\u00e8ses pour des parenth\u00e8ses. Pas d'accord ? Alors attendez le moment o\u00f9 l'abstraction au-dessus de la base de donn\u00e9es commencera \u00e0 fuir et vous commencerez \u00e0 lutter contre la fonction (raw-sql)<\/em><\/p>\n
Et que faire ? Laissez SQL en tant que SQL ordinaire \u2014 un fichier pour une requ\u00eate :<\/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 puis lisez ce fichier, en le transformant en une fonction Clojure simple :<\/p><\/blockquote>\n
<\/p>\n
(defqueries "some\/where\/users_by_country.sql"\n   {:connection db-spec})\n\n;;; Une fonction nomm\u00e9e `users-by-country` a \u00e9t\u00e9 cr\u00e9\u00e9e.\n;;; Utilisons-la :\n(users-by-country {:country_code "GB"})\n;=> ({:name "Kris" :country_code "GB" ...} ...)<\/code><\/pre>\n
<\/p>\n
En respectant le principe "SQL s\u00e9par\u00e9, Clojure s\u00e9par\u00e9", vous obtenez :<\/p>\n